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BACKGROUND OFTHE INVKNTION 
This invention relates generally to gaming devices, and more 
particulnrly to a method and apparatus fur controlling gaming devices 
interconnected by a computer network. 

Networked gaming devices are know in the art. Interconnecting a 
plurality of gaming devices such as slot machines via a aunputer network 
to n central computer provides many advantages. The prin.a ry advantage 
of networked gamingdevices is the ability to extract accounting data from 
the individual gaming devices as well as provi.ling playor tracku,g. An 
example of a data collection system is doscrihod in U.S. Pat.M.t No. 
4 283.709 issued to Lucero et al. Network sy.sl.r.us .such as doscr.l.cd m 
I 'ucero et al. allow the central host computer to monitor the u.a,;e and 
payout, collectively known as audit data, of th. individual gn.ning 
devices This audit data includes data related to the .unnber of corns or 
tokens inserted into the device, the number oftimes the device has boon 
phiyed. the amount paid in raises, the nun,her and the type of jackp<.ts 
paid by the machine, the number of door openings, etc. I 1h. host 
computer can then compile an accounting report base.l on the audit data 
from each of the individual gaming devices. This r.port can then he used 
hy management, for example, to assess the profitability ofthe individual 
yaminK devices. 

Player tracking, as the name indicates, involves tracking ind.v.dual 
player usage of gaming devices. In prior art player tracking sysUMus. the 
player is issued a player identification card which has enco<led thereon a 
player identification number that uniquely identifies the player. The 
individual gaming devices are fitted with a card rea<ler. into which the 
player inserts a player tracking card prior lo plnyiug H.o associated 

\/l 



gaming device. The card reader reads the player identincntion miinher 
olT the card and informs £ central computer connected thereto of the 
player's subsequent gaming activity. By tracking the individual players, 
individual player usage can be monitored by associating certain of the 
audit data with the player identification numbers. This allows gaming 
establishments to target individual players with direct marketing 
techniques according to the individual's usage. 

One problem that can occur with current player tracking systems 
is tbnt the player can insert a player identincation card incorrectly 
unbeknownst to the player. Currently, if a player inserts a player 
identification card improperly into the card reader, a message appears on 
a display located away from the card reader. Unfortunately, the player 
may not be looking at the display while inserting tiie card. As a result, 
the player may not see the message on tiie display. Another prior art 
approach has been to provide a light emitting diode on the gaming device 
to indicate to the player the status of the card insertion. This too has 
been ineffective because the player may not know the purpose-of the LED 
or the LED may be drowned out by all the other liglits of tlie casino. The 
player may therefore commence pl.nying with the card improperly 
inserted. In this case, both the player and the casino lose valuable player 
tracking information. This is frustrating for the player because his 
activity will not be credited to his account and frustrating for the c:i.sino 
because the casino's records will be incomplete. Accordingly, a need 
remains for an improved method and apparatus for informing the player 
when a player tracking card has been improperly inserted. 

The full power of networked gaming devices has not been coniplclcly 
realized. Although the audit data indicates which devices arc being 
under utilized and when, there is currently no automated method for 
altering under utilized gamingdevices' configurations to make them more 

attractive to play. For example, during certain hours of the day. e.g. four 



to six a-m.. the audit data may indicate that the machines arc being 
under utilized. TJms. it wouJd be desirable to reconfigure the under 
utilized gaming devices to provide an additional incentive to players to 
use these devices. In the past casinos have run "bonuses" during these 
times. An example of such bonuses include a "double jackpot" wherein a 
Dlayerhittingajackpotispaiddoublethejackpotamount. Currently this 
is implemented by having an attendant manually payout the additional 
payout amount This manual technique, however, is cumbersome and 
inefTicient to administer because an attendant must be constantly 
supervising the bonusing gaming devices. Accordingly, a need remains 
for an automated method and apparatus to provide bonusing for gnniing 
devices. 

Another limitation of the current bonusing systems is that only 
predetermined machine.* areTeligible for the bonusing. For example, in 
a progressive bonusing machine a plurality of machines are connected 
together to form a bank. Only the machines in the bnnk are then eligihle 
to win the progressive jackpot. Thus, a casino must dedicate a certain 
number of its machines to these banks. This limits the casino's Hexibility 
in tailoring its bonusing to the number and make-up of its customers. 
Accordingly, a need remains for a more flexible bonusing system whereby 
any of the casino's machines can participate in the bonusing. 

SUMMARY OF THE INVENTION 
It i.s, therefore, an object of the invention to reconfigure gaming 

devices remotely over a network to provide bonusing. 

Another object of the invention is to provide an integrated system 

usable with a variety of gaming devices made by difierent manufacturers. 
Another object of the invention is to integrate player tracking, data 

collection, and bonusing over the same network. 



A further object of the invention is to provide visual feedback to the 
user when a player tracking card has been improperly inserted. 

A system for operating networked gaming devices is described. The 
system according to the invention allows a casino in whicli the system is 
installed to run promotions or bonuses on any properly equipped gaining 
machines while simultaneously gatheringplaycr tracking and accounting 
data from all machines. The system provides the capability for the casino 
to select which of the plurality of machines are used in any given 
promotion. The system further allows any number of dilTerent 
promotions to operate simultaneously. 

The system includes a plurality of gaming devices or machines 
connected to an associated floor controller over a network. The system 
includes one or more of said floor controllers. The floor controllers are 
interconnected by a high-speed network, such as an Ethernet network, to 
a database where accounting and player tracking data is stored. The 
system can also include pit terminals and/or fill and jackpot processing 
terminals. Each promotion involves sending a reconfiguration command 
from the floor controller to a gaming device that has been selected to be 
part of a given promotion over the associated network. Upon receipt of 
the reconfiguration command, the gaming device reconfigures its payout 
schedule in accordance with the received reconfiguration command. In 
the preferred embodiment, this reconfiguration includes activating a 
bonus payout schedule. A partial list of the promotions according to the 
invention include, but are not limited to: a multiple jackpot wherein the 
gaming device reconfigures its payout to be a multiple of its default 
payout schedule; a bonus jackpot wherein the gaming device reconfigures 
its payout schedule to payout an additional bonus amount when certain 
conditions are met; and a progressive jackpot wherein two or more 
gaming devices are combined in a progressive jackpot having a 
progressive jackpot payout schedule. In addition to these, many other 



promolions arc possible by the above-described systen» fur controlling and 
monitoring a plurality of gaming devices. 

The system also allows for improved player tracking by recording 
each and every machine transaction including time of play, machme 
number, duration of play, coins in. coins out. hand paid jackpots and 
games played. The player tracking is conducted over the same network 
as the accounting data is extracted. This allows the invention to provide 
bonusing to certain individual players as well as during certain times. As 
with standard player tracking, the above-describcd systo.n n.onitors and 
reports how many coins .re played by each player. The system according 
to the invention, however, also includes the ability to record how long 
each player spends at each machine and the number of coins won. games 
played, and hand jackpots won by each player. The invention .s able to 
record all this information because the system operates on a transaction 
by transaction basis. Each 'transaction, whether it be a coin in. a handle 
pull. etc.. is recorded by the system. Other systems swnply compile the 
player tracking information at the completion of play. AH Hus 
information is stored on the database, which can be later analyzed for 
future targeted direct mailing campaigns. The player tracking according 
to the invention also allows the casino to schedule buses and other groups 
and measure their profitabiUty. The system also allows for cashless play 
as well as advanced accounting and security features. 

An advantage of the invention is that any of the casino's machines 
can be incorporated into a bonus promotion. 

Another advantage of the invention is that several bonus 
promotions can operate simultaneously. 

A further advantage of the invention is the ability lo record each 
and every machine transaction including time of play, machine number, 
duration of play, coins in. coins out. hand paid jackpots and games played. 



A further advantage of the invention is the abiUty to associate a 

player with a certain machine. 

A further advantage of the inven tion is the ability to perform more 
targeted direct mailing based on individual play. 

A further advantage of the invention is the ability to calculate a 

theoretical win exactly. 

A further advantage of the invention is the ability to generate 
jackpot announcements, which provides for. among other things, better 

slot tournaments. 

Ayetfurtheradvantageoftheinventionistheabilityloquicklyand 

easily add new machines to the network. 

The foregoing and other objects, features and advantages of the 
invention will become more readily apparent from the following detailed 
description of a preferred embodiment of the invention which proceeds 
with reference to the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 
FIG. 1 is an illustration of a system for monitoring and conr.guring 

gaming devices according to the invention. 

FIG. 2 is a block diagram of an electronic module associated with 

each gaming device to permit monitoring and configuring thereof. 

FIG. 3 is a schematic diagram of a data communication node of the 

electronic module of FIG. 2. 

FIG. 4 is a schematic diagram of a discrete machine interface circuit 

of the electronic module of FIG. 2. 

FIG. 5 is a schematic diagram of a player tracking module of the 

electronic module of FIG. 2. 

FIG. 6 is a schematic diagram of a card reader circuit of llu. 

electronic module of FIG. 2. 



FIG. 7A is an exploded view of a card reader accordii.K to the 
invention. 

FIG. 7B is a rear perspective view of the card reader of FIG. 7A. 
FIG. 70 is a front perspective view of the card reader of FIG. 7A. 
FIG. 8 is a schematic diagram of a display circuit of the player 

tracking module of FIG. 2. 

FIG. 9 is a schematic diagram of a personality board of the 

electronic module of FIG. 2. 

FIG. 10 is a schematic diagram of a triac driver circuit of the 

electronic module of FIG. 2. 

FIG. 11 is a sdiematic diagram of a relay driver circuit of tiie 

electronic module of FIG. 2. 

FIG. 12 is a block diagram of a communication board included in 

each floor controller of FIG. J.. 

FIG. 13 is a now chart for the power-on procedure for the data 
communication node (DON) of FIG. 2. which is implemented in firmware 

executed by the DON controller. 

FIG. 14 isaflow chart for processing of the discrete gaming device 

inputs, of FIG. 13. 

FIG. 15 is a now chart for the step of incrementing meter counts 
associated with each gaming device of FIG. 14. which is implemented in 
firmware executed by the DON controller. 

FIG. 16 is a now chart for the step of processing tlie serial interface 
between the gaming device and the data communication node of FIG. 13. 
which is implemented in firmware executed by the DCN controller. 

FIG. 17 is a How chart for the step of processing the network 
interface between the Hoor controller and the data communication node 
of FIG. 13, which is implemented in firmware executed by the DCN 
controller. 



FIG. 18 is a now chart for the step of processing the network 
message of FIG. 17. which is implemented in firmware executed by the 
DON controller. 

FIG 19 is a flow chart for the step of processing the data 
communication node request of FIG. 18. which is implemented in 
firmware executed by the DCN controller. 

FIG 20 is a now chart for the step of FIG. 13 of processing the 
player tracking interface, which is implemented in firmware executed by 

the DCN controller. 

FIG. 21 is a now chart for the step of processing a valid inserted 
card of FIG. 20. which is implemented in firmware execu ted by the DCN 
controller. 

FIG. 22 is a fiow chart for the step of processing player trackmg 
information of FIG. 21. which is implemented in firmware executed by the 
DCN controller. 

FIG. 23 is a fiow chart for the power-on procedure for the player 
tracking (PT) node of FIG. 2. which is implemented in firmware executed 
by the PT controller. 

FIG. 24 is a fiow chart for the step of processing the DCN interface 
of FIG. 23. which is implemented in firmware executed by the Fl' 
controller. 

FIG. 25 is a fiow chart for the step of processing the DCN message 
of FIG. 24, which is implemented in firmware executed by the IT 
controller. 

FIG. 26 is a fiow chart for the step of processing ll^e card render 
bezel update of FIG. 23. which is implemented in firmu'nro cxecutod l,y 

the PT controller. 

FIG. 27 is a fiow chart for the step of processing the card reader of 
FIG. 23. which is implemented in firmware executed by the PT controller. 



FIG. 28 is a flow chart for the power-on noor controller process, 
which is implemented in soawarc executed by the floor controller. 

FIG. 29 is a flow chart for the message processing step of FIG. 28, 
which is implemented in soaware executed by the floor controller. 

FIG. 30 is a flow chart for the message handling step of FIG. 29. 
which is implemented in software executed by the floor controller. 

FIG. 31 is a flow chart for the step of assigning uniq-ue machine 
addresses of FIG. 30, which is implemented in software executed by the 
floor controller. 

FIG. 32 is a flow chart for the system monitoring step of FIG. 28. 
which is implemented in software executed by the floor controller. 

FIG. 33 is a flow chart for the event handling step of FIG. 32. which 
is implemented in software executed by the floor controller. 

FIG. 34 is a flow chart for bonus control, which is implemented in 
software executed by the floor controller. 

DETAILED DESCRIFl'ION 
TnMff nfr!nnlfints 
I. SYSTEM ORGANIZATION 
A. SYSTEM OVERVIEW 
n. DATA COMMUNICATION NODE 

1. Overview 

2. CONTU01.I.EU ANi) Memory 

.3. NETWORK IN TERFACE 

4. SERIAL MACHINE INTERFACE 

5. SERIAI, niSIMJ^Y INTERFACE 

6. Discrete Machine Interface 

7. MACHINE CONFICURATION 



10 



15 



20 



25 



C. PLAYER TRACKING MODULI-: 

1. Overview 

2. SERIAU DISPLAY ClUCUIT 

3. Serial expansion ports 

4. Card Reader 

5. Display 

6. discrete input section 

D. PERSONALITY BOARD 

E. BONUS DISPLAY DRIVERS 

F. FLOOR CONTROLLER 
U. OPERATION 

A. DATA COMMUNICATION NODE 
1. POWER UP PllOCEnUUR 

2 READING UNIQUE IDKNTIFICATION NUMHI-U 

3. MONITORING GAMING DEVICK DtSCUCTi iNI'UT 

4. PROCESSING GAMING DEVICE SKIUAI. IN TKKFAri; 

5. PROCESSING NETWORK INTEUFACK 

6. PROCESSING PI AVER TRACKING INTKIM'ACE 

7. PROCESSING Card insertion 

B. PIJ^YER TRACKING MODULE 

1. POWER Up PROCEDURE 

2. PROCESSING DCN INTERFACE 

3. PROCESSING DlSPIAY UPDATE, 

4. PROCESSING BEZEL UPDATE 

5. PROCESSING Card Reader 

C. FLOOR CONTROLLER 

1. POWER Up Procedure 

2. MESSAGE Processing 

3. ASSIGNING Gaming Device Addhkssks 
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4. SYSTEM MONITORING 

5. BONUS CONTROL 



I. SYSTEM ORGANIZATION 

A. SYSTEM OVERVIEW 

A system for operating a plurality of gaming devices is shown 
generally at 10 in FIG. 1. The system, hereinaaer described, monitors 
and reconfigures a plurality of gaming devices or machines 12- IG and 22- 
26. The system includes the following capabilities: remote 
reconfiguration, accounting data extraction, integrated player tracking, 

cashless play. Remote reconfiguration includes sending a 
reconfiguration command from a host computer to one or more of the 
gaming devices. The gaming devices, on receiving a reconfiguration 
command, will reconfigure its jackpot payout schedule in accordance with 
the reconfiguration command. 

this reconfiguration, in the preferred embodiment, comprises 
activating a bonus payout schedule. This bonus payout schedules in 
addition to the normal pay Uible of the gaming device. The bonus payout 
schedule provides for additional bonus payouts in addition to the payouts 
specified by the device's normal pay table. The difTcrencc between the 
two is important for regulatory reasons. Tiie composition of the pay table 
is subject to regulation by the various state gaming commissions while 
Iho bonus payout schedule is not. The preferred embodiment currently 
activates only the bonus payout schedule responsive to the 
reconfiguration command, while not altering Iho payout table. The 
invention, however, is not limited to activating only the bonus payout 
.schedule. Other embodiments, which would bo subjccl to rotiulatory 
approval, could modify the device's payout table. The preferred 
embodiment, however, docs not. 
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The system, according to the invention, implements a variety of 
bonusing events through this reconfiguration process. These bonusing 
events include: a multiple jackpot wherein the gaming device reconfigures 
its payout to be a multiple of its default payout schedule; a bonus jackpot 
wherein the gaming device reconfigures its payout schedule to payout an 
additional bonus amount when certain conditions are met; and a 
progressive jackpot wherein two or more gaming devices arc c6mbtned in 
a progressive jackpot having a progressive jackpot payout schedule. 

The system, according to the invention, also provides for integrated 
player tracking and accounting data extraction. Unlike prior art systems 
that use disparate systems for player tracking and accounting data 
extraction, the system 10 provides for player tracking and accounting 
data extraction over the same network. The player tracking, according 
to the invention, allows the ci^sino to run certain promotional events. The 
integrated player trackingand accounting data extraction also allows the 
system to support cashless play wherein a credit is given lo a player over 
the network. 

The system 10 includes one or more floor controllers 18 and 28. 
Each floor controller supports up to a predetermined maximum number 
of gamingdevices. In the preferred embodiment, each floor controller can 
support up to 1024 gaming devices. The preferred embodiment also 
supports up to eiglit floor controllers. Thus, the system 10 can support up 
to 8192 separate gaming devices. 

The system supports a multiplicity of various gaming devices. Tl»c 
gaming devices 12-16 and 22-26 shown in FIG. 1 arc tiic typo liaviny a 
pull handl.-^ for initiating a game, e.g., .slot machines, llownvcr, the 
invention is not limited to such gaming devices. The gnnuue. devices 
shown in FIG. 1 can also be gaming tables or push button operntnd 
machines as well. e.g. video poker. As will be described hcreinnller. the 
system supports any gaming device providing traditional discrete 
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connections. e.g.. coins-in. coins-out. etc.. as well as those having serial 
interfaces, as described below. 

The noor controllers 18 and 28 are, in the preferred embodiment, 
IBM-compatible personal computers. Each floor controller is responsible 
for monitoring the activity level of the corresponding gaming- devices 
connected thereto and issuing commands to the associated gaming devices 
to reconfigure their payout schedules during certain bonusing events. 
The floor controllers issue status requests to each of the individual 
gaming devices to determine the acUvity level of each. In the event the 
floor controller detects any activity, the floor controller communicates 
that activity to a file server 32, which is connected to the floor controllers 
via a high speed network 38 connected therebetween. 

In the preferred embodiment, the file server 32 includes a high 
performance personal computer or work sUtion having a large hard disk 
capacity in order to store the gaming device activity therein. In the 
preferred embodiment, the high speed network 38 is a ten megabyte 
ethernet network. The system 10 also includes commercially available 
network soRware to support the industry-standard ethernet network 38. 
An example of such network soaware is Novell network soRware sold by 
Novell of Provo, Utah. The file server 32 also includes a databnse 
program by which reports can be generated using the data stored on Ihe 
file server. Such reports include, e.g. area, model, denomination and 
summary reports. The database soaware also allows a user to gnnerate 
custom reports. The database software is based on the industry- 
standard Paradox database language. 

The system 10 also includes a pit terminal 34 which is also 
connected to the ethernet network 38. The pit terminal 34 i.s also a 
standarii personal computer, in the preferred embodiment, and can he 
used to monitor the gaming device activity in the pit. This terminal 34 
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can also be used as a security monitoring device to detect any 
unanticipated events like fills or payouts. 

The system 10 further includes any number of fill and jackpot 
processing terminals 36. These terminals 36 are placed in the cage and/or 
the change booth areas of the casino for fill and hand-paid jackpot 
processing. When a fill is required, a Hoor person goes to the nearest 
cashier's booth and states the gaming device number requiring a fill. The 
booth attendant enters the number into the fill and jackpot processing 
terminal 36 located in the cashier's booth. The terminal 36 then looks up 
the record associated with the particular gaming device in the file server 
32 to determine the correct fill amount. The terminal 36 also calculates 
a theoretical hopper balance for the particular device based on the latest 
meter information, as described further below. If the calculation shows 
a significant hopper balance, a warning is given on the computer screen 
from which security can then be alerted. 

A fill and jackpot processing terminal 36 prints a fill ticket upon 
demand. If the calculated hopper balance was nearly zero, the tenninal 
36 cause the words "computer verified" to l)c printed on the ticket in place 
of a supervisor's signature. In the event that the calculated hopper 
balance was not near zero, an extra signature is required to complete the 
fill transaction. The system follows a similar procedure for processing 
hand-paid jackpots. 

A dispatch station (not shown) can also bo included in the system. 
The dispatch station allows the casino to monitor activity on the gaming 
devices and "run the casino" from one location. The dispatch station 
allows the dispatcher to monitor customer service, maintenance, and 
security events and direct other casino personnel to handle these 
situations appropriately. For example, during hopper nniptios (fills) and 
jackpot events, as indicated by the dispatcher station, the disiKitcher 
could radio down to the floor to have someone verify the event. The 



dispatcher station can also indicate when a machine door is opened 
without a technician card inserted, for example, in which case the 
dispatcher could take the appropriate course of action. 

The above-described system 10 is but one embodiment of the system 
according to the invention. The system tasks can be allocated in a variety 
of ways amongst the system computers including floor controllers 18 and 
28, file server 32. pit terminal 34 and fill and jackpot term.inals 36. In 
some cases, the pit terminal 34 and fill and jackpot terminals 36 can even 
be ehminated and their tasks allocated to the floor controller or Hie 
server. In fact, because the file server 32 is e.'^sentially a virtual hard disk 
for the floor controllers 18 and 32, the floor controllers and the file server 
can be considered a single host computer for the system 10. 

B. DATA COMMUNICATION NODE 
1. Overview 

' In order to communfcate with the floor controller, each gaming 
device includes therein an electronic module 40. as shown in FIG. 2. This 
module 40 can be inserted into a variety of pre-existing gaming devices. 
The module allows the host computer to uniquely identify the gaming 
device on the network, including the device type. The module 40 includes 
two main subcomponents: a data communication node 42 and a player 
tracking module 44. The data communication node 42 keeps track ofthe 
coins-in. coins-out. coins to drop, games played, jackpot occurrences and 
other related functions of the associated gaming device. The player 
tracking module 44 keeps track of the player that is playing the 
associated gamingdevice. Together, thedata communication node 42 and 

the player tracking module 44 allow the floor controller connected to the 
associated gaming device to monitor and control the activity of the 
gaming device. The system hereinafter described in detail includes the 
following capabilities: slot accounting, player tracking, bonus jackpots 
and cashless play. 
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2. CONTnOLLER AND MEMORY 
The data communication node (DCN) 42 includes a data 
communication node controller 46, which in the preferred embodiment is 
an HD6473258P10 controller manufactured by Hitachi of Tokyo. Japan. 
The DCN 42 is coupled to the player tracking controller 44 through bus 
interface logic 45. The bus interface logic 45 is conventional interface 
logic including, for example, transceivers, as is known in the art of digital 
design. 

A memory 48 is connected to the DCN controller 46. The memory 
includes program memory for storing program instructions for the DCN 
controller 46. In the preferred embodiment, this program memory 
includes a nonvolatile read-only memory (ROM). However, this program 
memory could also be flash or "battery" backed RAM in order for the 
program memory to be updated by the noor controller. In the event flash 
or "battery" back RAM is used the noor controller would download the 
updated program to the DCN controller and the DCN controller would 
overwrite the program memory with the downloaded program. 

The memory 48 also includes systerr. memory, e.g.. static random- 
access memory (SRAM) for storing the gaming device information. This 
gaming device information includes at least the following meters: coins- 
in. coins-out, coins to drop, games played, jackpot occurrences. A 
separate meter counter is kept in memory 48 for each of these values. To 
increase reliability of the data, in the preferred embodiment, a redundant 
set of these counters is kept in a physically separate memory device 
within memory 48. Moreover, the memory devices storing these counters 
are nonvolatile so that in the event of a power failure the counts will be 
retained. The nonvolatile memories can either be battery-backed SRAM 
or electrically erasable programmable read-only memory (K13IM10M). 
Although memory 48 is shown external to DCN controller 46. much ifnot 
all of the memory 48 can be included in the DCN controller 46. 
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3. Network interface 

The data communication node 42 also includes a network interface 
49 for connecting the data communication node 42 to the associated floor 
controller. The network interface is coupled to the floor controller 
through a personality board 202, described below. 

A more detailed drawing of network interface 49 is shown in FIG. 
3. In FIG. 3, the DCN controller 46 receives data from the floor controller 
over conductor 52 which is optically isolated from a connector 51 by 
optical isolator circuit 54. The DCN controller 46 transmits data to the 
floor controller over conductor 56. which is optically isolated from the 
connector 51 by optical isolator circuit 58. Each of the opto-isolator 
circuits 54 and 58 include an opto-coupler as are known in the art. A bus 
222 (FIG. 2) is connected between the network interface 49 and the 

personality board 202. ' 

4. Serial Machine Interface 

Referring to FIG. 2. the daU communication node includes a serial 
machine interface 60. The serial machine interface 60 allows the data 
communication node 42 to communicate with the associated gaming 
device advance serial interface as contrasted with the discrete interface, 
to be described further hereinaaer. A bus 224 (FIG. 2) connects the 
serial machine interface 60 to the associated gaming device at connector 
62. The serial interface, in the preferred embodiment, is a standard RS- 

232 three wire interfacis. 

Referring to FIG. 3. the DCN conlrollcr 46 receives data from lUe 
gaming device over conductor 64 which is connected between the DCN 
controller 46 and a differential to single-ended converter 6G. The DCN 
controller 46 transmits data to the gaming device over conductor G8 
connected between the DCN controller 46 and the converter GG. The 
converter 66 converts the difl-ercntial inputs of the serial inlerfnce G2 to 
a single-ended output which is transmitted over conductor 64 to the DCN 



controller 46. The converter 66 also converts the single-ended input 
received from the DCN controller 46 to a differentinl output signal and 
transmits that to the serial interface 62. The serial machine interface is 
the means by which the DCN controller communicates certam 
reconfiguration data, referred to as reconfiguration commands, to the 
machine. These reconfiguration commands cause the machines to 
activate a bonus payout table to allow the machine to append bonus 
payments to their standard jackpot payouts, as specified by their payout 
table, during certain bonus activities. 

5. SERIAL DISPLAY INTERFACE 

The data communication node 42 further includes a serial display 
interface 70 illustrated in more detail in FIG. 3. The serial display 
interface 70 includes logic coupled between the DCN controller 46 and an 
expansion connector 71. The expansion connector 71 allows tlie DCN 
controller 46 to communicaee with an expansion device connected thereto. 

6. Discrete Machine interface 

The data communication node 42 also includes a discrete machine 
interface 72. which is shown in detail in FIG. 4. The discrete machine 
interface 72 includes a plurality of opto-couplers 78 coupled between the 
discrete outputs from the gaming device or machine and the DCN 
controller 46. The discrete outputs of the machine are received at 
terminals 74A-74J of a connector 74 via a cable (not sl'.own) connected 
between the machine and the connector 74. The discrete outputs arc 
coupled to corresponding inputs 76A-76J via opto-couplers 78. Tho 
discrete outputs from the machine include: an EXTRA signal, a POWER 
signal, a COIN IN signal, a COIN OUT signal, a COIN DROP signal, a 
JACKPOT signal, a HANDLE signal, a TILT signal, a SLOT DOOR 
signal, and a DROP DOOR signal. Each of these signals correspond to a 
known event in the machine. For example, when a coin is dropped in the 
machine a COIN IN signal- appears on terminal 74C. This COIN IN 
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signal is then transmitted to the DCN controller 46 on lino 76C via the 
associated opto-couplcr. 

All of the signal lines 76A.76J include a pullup resistor and a 
pulldown capacitor, which combined form an RC network on the 
associated line. The resistors are. in the preferred embodiment, in the 
form of a resistor pack 80 and the capacitors are individual discrete 
capacitors 82. Alternatively, the capacitors can be removed for high- 

speed signals. 

7. MACHINE Configuration Circuit 

The data communication node 42, as shown in FIGS. 2 and 3, 
further includes a machine configuration circuit 84. In the preferred 
embodiment, as shown in FIG. 3. the machine configuration circuit 84 
includes a parallel to serial converter 86, which includes eight parallel 
inpute IN. a serial input SIN.,a clock input CLK. a strobe input STB. and 
a serial output SOUT. The parallel inputs IN are connected to a 
personality board, as described hereinafter, to receive a unique machine 
configuration number therefrom, which uniquely identifies the' type of 
machine that the data communication node is connected to. In the 
preferred embodiment, the machine identification number is comprised 
of six bits. Therefore, the two remaining parallel inputs can be used to 
provide additional inputs, such as additional discrete machine inputs, to 
the DCN controller 46. 

The machine configuration number presented on the parallel inputs 
of the parallel to serial converter 86 is latched therein responsive to a 
strobe signal received at the strobe STB input. A strobe input is 
generated by the DCN controller 46 on conductor 90 which is coupled to 
the strobe STB input. The parallel data is clocked out of tlie converter 86 
to tlie DCN controller 46 on conductor 88 and connected between the 
serial output SOUT of the converter 86 and an input of the DCN 
controller 46 responsive to a clock signal received on the clock input CLK 



of the converter 86. The dock signal is generated by the DCN controller 
46 and is transmitted to the converter 86 via conductor 92 which is 
coupled between an output of the DCN controller 46 and the clock input 
CLK of the converter 86. 

The converter 86 also includes a serial input SIN for receiving serial 
input data. The serial input SIN is coupled to an expansion terminal 94C 
of expansion connector 94. Conductora 90 and 92 are also coupled to the 
expansion terminal 94 to provide the clock and strobe signals thereto. 
The expansion terminal 94 therefore provides the means for the DCN 
controller 46 to access additional serial information through the parallel 
to serial converter 86. In the preferred embodiment, the parallel to serial 
converter 86 is part number 4021 manufactured by Toshiba Corporation 

of Tokyo, Japan. 

C. PLAYER TRACKING MODULE 
1. Overview 

Referring again to FIG. 2, the module 40 coupled to each of the 
gaming devices includes a player tracking module 44. The player 
tracking (PT) module 44 includes a player trncking controller 98, a card 
reader 100, a serial display driver 101, a display 102, and expansion 
interfaces 104 and 106. The player tracking controller 98 communicates 
with the data communication node controller 46 through bus interface 
logic 110. The DCN controller 46 and PT controller 98 maintain a 
master-slave relationship, respectively. Therefore, all communication is 
initiated by the DCN controller 46. The bus interface logic is 
conventional logic and its design is well-known in the art of digital 
electronics. 

In the preferred embodiment, the player tracking module 44, with 
the exception of the card reader 100 and the display 102, resides on a 
single printed circuit board, while the data conununication node 42 
resides on a separate printed circuit board. The player tracking module 
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44 and the data communication node 42 arc then connected by a cable 1 1 1 

sucli as a ribbon cable. 

2. SERIAL DISIMJVY ClUCOlT 

Amore detailed drawing of the player tracking module 44 is shown 
in FIG. 5. In FIG. 5. the serial display circuit 101 includes a transistor 
Ql and a resistor Rl connected to the base thereof. A conductor 112 is 
connected between the PT controller 98 and the resistor Rl to. provide a 
drive signal to transistor Ql. The drive signal causes transistor Ql to 
conduct a current and thereby drive a display connected to the collector 
of Ql at a terminal 114 of a connector 1 15. In the preferred embodiment, 
the terminal 114 is connectable to a small vacuum Ooresccnt display to 
provide serial display data thereto. 

3. Serial Expansion Ports 

The player tracking module 44 also includes two serial expansion 
ports 104 and 106. Each of the expansion ports 104 and 106 includes a 
dilTerenUal to single-ended converter 116 and 118. respectively. In the 
preferred embodiment, these converters 116 and 118 are part number 
LTC490 manufactured by Linear Technology Corporation of Milpitas. 
California. The FT controller 98 communicates with each converter via 
two single-ended, serial signal lines: an input signal line and an output 
signal line. The converters convert the single ended signals appearing on 
these lines to differential signals. The differential signals, however, can 
be used as single-ended signals as is known in the art. The first 
expansion port 104 interfaces the player tracking node 44 with a large 
vacuum florescent display 102 (FIG. 5) used to display player tracking 
messages, as described further below. The display is connected to the 
connecter 115. in the preferred embodiment, by a cable 103. The other 
expansion ports 106 provides the player tracking module will» future 
expansion capabilities to support additional features. 



30 



21 



4. Card reader 

Referring now to FIGS, 6 and 7. the card reader 100 will now be 
described. FIG. 6 shows the electrical sdiematic for the card reader while 
FIG. 7 shows the mechanical drawing Uiereof. In FIG. 7A. an cxph)ded 
view of the card reader is shown. The card reader includes a plastic bezel 
1 16 having a card reader opening 118 formed thercalong for receiving a 
card 120 therein. The bezel 1 16 includes guide rails 122 and 124 disposed 
at opposite, respective lateral ends of the opening 118. The guide rails 
122 and 124 have stops 126 and 128. respectively. The guide rails 122 
and 124 guide the card 120 through the opening 118 until an end of the 
card 120 contacts stops 126 and 128. The card is shown fully inserted in 
FIGS. 7B and 7C with the end of the card 120 abutting the stops 126. 128. 

The card reader also includes a printed circuit board 130 having a 
longitudinal opening to allow the guide rails 122 and 124 to be inserted 
therein in order to allow the printed circuit board 130 to be pushed up 
flush against a mounting plate 132 of the bezel 116. as shown in FIGS. 7B 
and7C. Mounted on one side of the printed circuit board 130 is an array 
of photodiodes 134 and an array of photodetcctors 136. The photodiodcs 
134 are mounted on the printed circuit board along one side of the 
opening in the printed circuit board, while the photodetcctors 136 are 
mounted on the printed circuit board along an opposite side of the 
opening. The photodiodcs and the photodctectors are vertically aligned 
in a one-to-one relationship, i.e.. one photodiode for each pliotodetcctor. 
In the preferred embodiment, the array of photodiodes includes eight 
individual diodes spaced equidistance along the opening in the printed 
circuit board 130. The photodiodes 134 are mounted along the opening 
in the printed circuit board 130 so as to align with separate rows of 
openings in the card 120. as described further below. The card reader 
also includes optional light masks 138 and 140. The light mask 138 is 
associated with the array of photodiodes 134 and has a plurality of 



openings therein, each opening corresponding to an indi vi<lual plioloditMlu 
in the array 134. Similarly, light mask 140 is associnlnd with the army 
of photodetcctors 136 and also has one opening Tor each of the 
photodetectors. The light mask 138 is mounted on the printed circuit 
hoard 130 beneath the array ofphotodiodes 134 along the oponing in the 
printed circuit board 130. The light mask 138 is aligned with the 
photodelcqtors 134 so that the openings in the light mask 138 are directly 
beneath a corresponding photodiode in the array. The light mask 138 
minimizes the amount of light emitted by a photodiode that can he 
detected by a photodetector other than the corresponding pliotodetcctor. 
The'llght mask 140 is mounted on top of the photodetector array 136 so 
that the openings therein align with the individual photodetectors. The 
light mask 140 further eliminates extraneous light from the photodiodes 
as well as extraneous ambient light. 

Also mounted on the printed circuit board 130 are a plurality of 
light-emitting diodes 142, as shown in FIG. 7C in broken line. The light- 
emitting diodes are mounted on a side of the printed circuit board 
opposite the side on which the photodiodes and photodetcctors are 
mounted on. The light-emitting diodes 142 are mounted around the 
perimeter of the opening in the printed circuit board 130 and are received 
in a recessed portion 144 of the bezel 116. The light-emitting diodes 142 
comprise a means for providing visual feedback to a user inserting a card 
120 into the bezel 116. as described further below. In the preferred 
embodiment, the light-emitting diodes 142 arc dual light-emitting diodes 
capable of producing two primary colors and a third combination color. 

Referring now to FIG. 6, an electrical schematic of the card reader 
is shown. The schematic includes the array ofphotodiodes 134 disposed 
along one side of the card reader opening 118 and tlie array of 
photodetectors 136 disposed along the opposite side of the opening 1 18. 
In the preferred embodiment, there are eight photodiodes and eight 



corresponding photodctcctors. The photodiodcs are arrani'cd in pairs, 
witli the two photodiodcs within each pair bcinc connected in a serial 
fashion. The anode of the first photodiodc in the pair is coupled Ui the 
supply voltage through resistor, while the cathode ofa second photodiodc 
in the pair is connected to an output of a driver circuit 144. The driver 
circuit, in the preferred embodiment, includes two open collector inverters 
connected in parallel. A signal is provided to the driver circuit 144 by llic 
PT controller 98 over a conductor 146. A signal on conductor 14G causes 
the driver circuit 144 to conduct current and thereby actuate the 
photodiodcs 134 substantially simultaneously. 

The photpdetcctors 136 arc comprised of a plurality of iight- 
scnsitive phototransistors PD1-PD8. The emitters of the phototransislors 
PDl-PDS are all coupled to ground. The collectors of pholotransisLor I'D I 
and PD8 are connected together and to a conductor 148 by which the PT 
controller 98 senses light detected by either phototransislor PD 1 or PD8. 
Phototransistors PD2 and PD7 are similarly connected with the collectors 
of each being connected to a conductor 150. The collectors of 
phototransistors PD3 and PD6 are also commonly connected to a 
conductor 15.2. The collectors of the center phototransistors PL)4 and 
PD5, however, are connected to separate conductors 156 and 154, 
respectively. Also connected to each of the conductors 148-156 is a 
corresponding pullup resistor. In the preferred embodiment, the pullup 
resistors are included in a resistor pack 158. Each of the conductors 148- 
156 are connected to a connector 170, which is coupled to the IT 
controller 98 as described below. 

Based on the above configuration of the phototransistors PDl and 
PD8, only five conductors are required to sample all eight of Ihc 
phototransistors. Without more information, however, the player 
tracking controller 98 would be unable to determine which of the two 
phototransistors commonly connected to a particular conductor, e.g., 
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conductor 148, detected liglit. For example, ifeithor])hololr;insistor IM) I 
or photolransistor PD8 detect light, the voltage level on conductor M8 
will drop from a high voltage of approximately 5 volts to a low voltage; of 
approximately 0.7 volts. Without more information, the player tracking 
controller 98 would be unable to determine which of the two 
pliototransistors, PDl or PD8, actually sensed the light. According to the 
invention, however, the card 120, as shown in FIG. 7A, includes a first 
slot 150 by which the PT controller 98 can determine which of the two 
photodetcctors detected the light, as described below. 

The card 120 includes five rows of slots 152- 16U. The rows of slots 
152-160 arc arranged in a matrix with the corresponding slot locations 
within each of the rows being aligned in columns. Only the first slot 150 
of row 152 cannot be aligned with any other slots, i.e., .slot 150 is in a 
column all by itself. The individual slots wiihin the rows of slots 152- 
160 encode unique player tracking information. Each slot represents a 
single binary bit in the player tracking information. Either one of two 
conventions can be used to encode the information. First, a slot can 
represent a binary 1 and no slot can represent a binary 0. Second, a slot 
can represent a binary 0 and no slot can represent a binary 1. The player 
tracking information can include: a unique player idt:ntification number, 
the casino issuing tlie card, player membership information, etc. 

In the preferred embodiment, the card includes five rows of slots 
each having a maximum number of nine individual slots, thereby 
producing 45 possible slots. The first row of slots 152, however, is not 
used to encode player tracking information, but instead is used to 
synchronize the samplingof the player tracking information by the player 
tracking controller 98. Thus, only 36 slots are used to encode player 
tracking information in the preferred embodiment. This still allows 2'^'^*'' 
possible combinations, which is more than adequate. 



The PI' controller 98 uses the first row 152 to synchronize the 
sampling as follows. The PT controller 98 continuously samples the 
outputs of PD4 and PD5 looking for a slot. If a slot is detected on either 
PD4 and PD5 and no other slots are detected by any other 
phototransistors the PT controller 98 determines that the detected slot 
must be slot 150. The PT controller 98 then continuously samples the 
output of the phototransistor that detected slot 150. Once a new slot is 
detected by that phototransistor, the PT controller 98 then samples the 
outputs of the other phototransistors, i.e., PD1-PD3 and PD6-PD8, on 
conductors 148, 150 and 152 for slots in of the other rows. Thus, the PT 
controller 98 synchronizes the sampling of the other rows of slots to the 
detection of a slot in the first row 152. 

It is important for the card reader to detect the orientation of the 
card in order to correctly interpret the player identification information 
encoded on the card. The card reader detects the orientation of the card 
120 by detecting the slot 150. If slot 150 is detected by phototransistor 
PD4, then the card reader knows that the card is in theorientatidn shown 
in FIG. 7A. In that case, the card reader knows that the player tracking 
information is actually being detected on phototransistors PD5-PD8, and 
can interpret the player tracking information accordingly. If, however, 
phototransistor PD5 detects slot 150, then the card reader knows that the 
card 120 is oriented 18D degrees from that shown in FIG. 7A. In that 
case, the card reader knows that the player tracking information is being 
detected by phototransistors PD1-PD4, and can interpret the information 
accordingly. The PT controller 98 can simply transpose the player 
tracking information sensed on conductors 148-152 depending upon the 
detected orientation of the card. Thus, the card render according to the 
invention is able to correctly interpret the player tracking information 
regardless of how the player inserts the card 120 into the bezel 116 of the 
card reader. The invention is able to accomplish this with only five 
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conductors between the eight phototransistors PD1-P08 and the PI' 
controller 98. 

The card reader further includes a plurality of light-emitting diodes 
142 that are mounted on the printed circuit board 130 and received in the 
recess 144 of the bezel 116, as shown in FIG. 7C. The LEDs 142 are 
mounted on the printed circuit board 130 so as to surround the card 
reader opening 118 as shown in FIG. 6. In the preferred embodiment, the 
card reader includes 24 dual diodes arranged in pairs. The dual diodes 
have two separate diodes, each being able to emit a diflcrent primary 
color of light In the preferred embodiment, the dual diodes emit either 
red or green light The dual diodes can also emit a third combination 
color if the two individual diodes in the dual diode are actuated 
simultaneously so that the two primary colors combine. In the preferred 
embodiment this combination color is approximately orange due to the 
difTcrences in the intensities of the red and green light. 

The dual diodes are essentially treated as two individual diodes. 
The red diodes R in the dual diodes arc driven by a driver circuit 162, 
while the green diodes G in the dual diodes are driven by another driver 
circuit 164. The driver circuits 162 and lb 5 are, in the preferred 
embodiment, two open collector drivers connected in parallel, as witli 
driver 145. However, other equivalent driver circuits would be apparent 
to those skilled in the art. 

The dual diodes are arranged in pairs with the anodes ofonc of the 
dual diodes being coupled to the supply voltage +5V and the cathodes of 
the other dual diode being connected to the output of the corresponding 
driver circuit. Accordingly, the red diodes are commonly driven by driver 
circuit 162, which is responsive to a signal received from the PT controller 
98 on conductor 166. Similarly, the green diodes are commonly driven by 
driver circuit 164, which is responsive to a signal received from the PT 
controller 98 on conductor 168. Therefore, the PT controller 98 can 
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selectively actuate the red diodes, the green diodes or both by generating 
the corresponding signals on conductors 166 and 168. 

All of the conductors over which the PT controller communicates 
with the card reader^ i.e.» 146-156 and 166-168» are connected to a 
connector 170 as shown in FIGS- 6 and 7A. The player tracking module 
44 then includes a cable 172 that is connected between the connector 170 
and the PT controller 98, as shown in PIG. 5. 

Although the preferred embodiment of the card reader is an optical 
card reader, the invention is not limited to such. The lighted bezel can be 
used in conjunction with any form of card reader such as a magnetic card 
reader, a bar code reader, etc The method of providing visual feedback 
to the player herein described is ^ general method which can be used with 
a plurality of cards and card readers. 

5. Display: 

Referring now to FIG. 8. a schematic for the display circuit 102 of 
the player tracking module 44 is shown. The circuit 102 includes a 
display controller 174, which in the preferred embodiment is a part 
number nD6473258PI0 manufactured by Hitachi of Tokyo, Japan. 
Coupled to the display controller 174 is a memory 176 via bus 178. The 
memory 176, in the preferred embodiment, is a 32KB SRAM. The 
memory 176 stores the variables and parameters necessary for the 
controller 174 to communicate with both the PT controller 98 and the 
display driver 186. The bus 178 includes the necessary address lines, 
data lines and control lines to interface in memory 176. 

In the preferred embodiment, the disphny 102 includes a vacuum 
fluorescent display (VFD) 184, which is organized as a 16 x 192 display 
matrix. Such displays are well-known in the art of digital electronics. 
The VFD 184 is driven by a driver circuit 186, which includes a plurality 
of individual drivers serially interconnected. In the preferred 
embodiment, these serial drivers are part number UCN5818EPF-1, 
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manufactured by Allegro Microsystems, Inc. of Worcester, Massachusetts. 
The driver circuit 186 is connected to the VFD 184 by bus 188. which 
includes 160 individual conductors. The manner in which the 160 bus 
lines are connected between the driver circuit 186 and the VFD 184 is 
known in the art, and is therefore not described in detail herein. 

The display controller 174 interfaces with the driver circuit 186 by 
a plurality of signal lines 190. These signal lines transmit the standard 
driver interface signals to the driver circuit 186. These signals include: 
a clock signal CLOCK, serial input data signal SDATA, a frame signal 
FRAME, a strobe signal STROBE, two output enable signals OEl/ and 
OE2/, a column clock signal COL CLOCI^ and a column output enable 
signal COL OE/. These signals have well known functions in the display 
art and are therefor not discussed in detail. The signal names having a 
" / " represent active low signals while all other signals are active high. 
The display controller 174 generates these signals in the renuired 
sequence in order to serially clock the reformatted display data to the 
driver circuit. One of ordinary skill in the art could program the display 
controller 176 to generate these signals in order to display the desired 
message on the VFD 184 based on the foregoing description. 

The display 102 also includes a serial interface 192. The serial 
interface 192 is the means by which the PT controller 98 communicates 
a player tracking message to the display 102. In the preferred 
embodiment, the serial interface 192 includes two opto-isolator circuits: 
one for the serial send data, the other for the serial transmission data. 
The display controller 174 is connected to the serial interface 192 over a 
two conductor serial bus 194, one conductor for receiving serial data from 
the serial interface 192, the other for transmitting serial data thereto. A 
connector 196 is also coupled to the serial interface 192. The connector 
196 includes four terminals. Two of the connector terminals are 
dedicated to receiving serial input data and the other two terminals are 



dedicated to transmitting serial daUi. A cable (not shown) couples the 
display 102 to the player tracking module 44 between connectors 196 
(FIG. 8) and connector 115 (FIG. 6). 

6. DISCRETE Input Sechon 

The display 102 further includes a discrete input section 198. The 
discrete input section 198 is an interface between the discrete outputs of 
a gaming device and the display controller 174 much in the same way 
that the discrete machine interface 72 allows the data communication 
node to interface with a gaming device. Although in the preferred 
embodiment the discrete input section is unconnected to any discrete 
machine inputs, the discrete input section 198 allows the display 102 to 
operate as a stand-alone module for gaming devices in certain 
configurations. The discrete inputsection provides discrete input signals 
from an external device to the display controller 174 over a bus 200. The 
discrete input section 198 includes opto-isolator circuits such as part 
number TLP62G manufactured by Toshiba Corporation of Tokyo, Japan 
which provide single-ended input signals to the display controller 174. 

D. PERSONALITY BOARD 

Referring now to FIG. 9, a personality board 202 is shown in 
schematic form. The personality board 202 uniquely identifies the 
gaming device on the network. The personality board 202 indicates the 
type of gaming device, e.g., slot machine or video poker, including the 
manufacturer, and provides a unique machine identification number that 
the host computer can use to uniquely address the gaming device. The 
personality board 202 allows the devices to be readily removed and 
reinstalled in the network without any manual reconfiguration by the 
operator, such as resetting dip switches. 

The personality board 202 couples the data communication node 42 
to a gaming device. The personality board 202 includes two connectors 
204 and 206 and an identification circuit 208. The connector 204 couples 



to the data communication node 42, as described AirUicr below. The 
connector 206 connects to the particular gaming device. The components 
shown in FIG. 9 are mounted on a printed circuit board tliat is mounted 
inside a connector harness (not shown). The personality board allows the 
DCN to be easily removed and reinstalled from the network with minimal 
cfTorL 

The personality board uniquely identifies the machine by providing 
both a configuration number, which indicates the type of gaming device 
that is connected to the connector 206 and a unique identification 
number, which is used by the system 10 to maintain records on the 
machine. The configuration number includes a six bit binary number 
which indicates the type of gaming device connected to the personality 
board 202. Each madiine type is assigned a unique configuration 
number. This configuration jiumber is encoded on lines CNFG0-CNFG5, 
which are connected to term'inals 204Q-204V, respectively, of connector 
204. Each line represents one bit of the binary configuration number. 
The individual lines are either tied to a supply voltage to represent a 
binary one or to ground to represent a binary zero. The six bit 
configuration number used in the preferred embodiment can encode up 
to 2"^ dificrent combinations and, therefore, different machine types. 
The configuration number for the embodiment shown in FIG. 9 is equal 
to 3CH. 

The configuration lines CNFG0-CNFG5 are coupled to the inputs of 
parallel to serial converter 86 <FIG. 3) through a connector (not shown). 
The terminals 204Q-20'1V of connector 204 have corresponding terminals 
85Q-85V of connector 85, as indicated by corresponding lettered suffixes. 
This same lettering convention is used throughout. 

Tiie configuration number is used by the DCN controller 46 as a 
means of interpreting the discrete input signals received from the 
machine through connector 206. Individual conductors coupled between 



connector 204 and 206 are labeled to correspond to the machine type 
having a connguratibn number 3CH. For a different machine typo having 
a different configuration number, many of these conductors may have 
different functions. By providing a unique configuration number, the 
DON controller can interpret the signals received on these lines 
accordingly. 

The personality board 202 also includes an identification circuit 208 
which provides a unique machine identification number to the data 
communication node 42. The unique identification number is stored in 
a nonvolatile memory 210 and provided to a terminal 204N on conductor 
ID. In the preferred embodiment, the nonvolatile memory 210 is a part 
number DS2224 manufactured by DallasSemiconductor of Dallas, Texas. 
In the preferred embodiment, the nonvolatile memory 210 includes a 32 
bit ROM having a factdry-lasered unique serial number stored therein. 
This serial number, i.e., the machine identification number, can be read 
out of the memory 210 by the DCN controller 46 to uniquely identify the 
machine connected thereto. The protocol for reading the identification 
number out of the memory 210, as is described in the data sheet for the 
part, is well known in the art. 

The identification circuit 208 includes a number of discrete 
components. The memory 210 has a zener diode 212 coupled across the 
power and ground terminals of 213 and 215 thereof. The identification 
circuit 202 also includes a first diode 214 coupled between the power 
terminal 213 and a data output terminal 217. The circuit 208 further 
includes a second diode 216 coupled between the daU output terminal 
217 and the ground terminals 215. A resistor 218 is interposed between 
the data output terminal 217 and the Connector terminal 204N. Tiic 
terminal 204N is coupled to a corresponding terminal 74N of connector 
74 (FIG. 4) by a bus 220 (FIG. 2). 
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The discrete outputs from the machine, e.g., coin in, coin out, etc., 
are niso supplied to the data communication node 42 via bus 220. The 
bus 220 connects connector 74 of the data communication node 42 and the 
connector 204 of the personality board 202 such that terminals having 
corresponding lettered suffixes are connected. For example, terminal 74C 
of connector 74 is connected to terminal 204C of connector 204 by a 
individual conductor within bus 220. All the other terminals are similarly 

connected by the bus 220. 

The network interface 49 of the data communication node 42 is also 
coupled to the personality board by a bus 222, as shown in FIG. 2. Bus 
222 includes four conductors which connects the four terminals of 
connector 51 with four corresponding terminals of connector 204, as 
indicated by the common lettered suffixes. It is over these four lines that 
the DON controller 46 indirectly communicates witli tlie floor controller. . 

The serial machine interface 60 is also coupled to the personality 
board 202 by a bus 224, as shown in FIG. 2. The bus 224 includes four 
conductors which couple four terminals 62DD and 62EE of connector 62 
with corresponding terminals 204DD and 204EE, respectively. It is over 
these four conductors that the DON controller 46 communicates 
reconfiguration commands to the machine. The DON controller transmits 
data through the terminal 204DD, which is provided to the machine on 
conductor MACHINE RX. The machine responds to the configuration 
command on the conductor MACHINE TX. The use of these two 
conductors will become more apparent in the description of the operation 
hereinbelow. 

Although buses 220, 222, 224 and 226 have been described as 
separate buses, the individual conductors within these buses could, and 
are in the preferred embodiment, combined into a single bus that is 
connected between the daU collection node 42 and the personality board 
202. To connect the data collection node 42 and the personality board 202 
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a connector (not shown) is mounted on the daU collection node 42 and a 
mating connector (not shown) is mounted on the personaUty board 202. 
The two connectors are then mated together to connect the data collection 
node 42 to the personality board 202. The personality board is then 
I coupled to the corresponding gaming device by a cable 225 (FIG,2). 
E. BONUS DISPLAY DRIVERS 

Referring now to FIGS. 10 and 11. two bonus display drivers are 
shown. The data communicaUon node 42 is designed to support either of 
the display drivers. The data communication node 42 is coupled to the 

,0 display driver of FIG. 10 through connector 228. An opto coupler 230 
optically isolates the data communication node from a triac circuit 232 
which includes a triac 234. One terminal of the triac 234 is connected to 
a terminal 236B of a connector 236. Another terminal of the triac 234 is 
connected to a terminal 2360 of connector 236. A bonus display such as 

IS a light or sound generaUng means is coupled across terminals 236B and 
236C so that the triac 234 could drive the external bonus display 
responsive to an actuation signal from the data communication node 42. 

A second embodiment of the display driver is shown in FIG. 1 1. In 
this embodiment, thedata communication node 42 is coupled to the driver 

20 circuit through connector 238. The driver circuit of FIG. 1 1 includes a 
relay 240 operatively coupled to a transistor 242. The relpy 240 is a two- 
position relay which toggles between the two positions responsive to a 
current passing through transistor 242. The transistor 242 conducts a 
current responsive to an actuation signal received on terminal 238B from 

25 the data communication node 42. 

The display drivers are used by the date communication node 42 to 
activate a display on the gaming device which indicates that the machine 
is now in a bonus mode or condition. 



30 



34 



F. FLOOR CONTROLLER 

As shown in FIG. 1. the floor controller is directly connected to both 
the high speed network 38 and a plurality of gaming devices. The floor 
controller is responsible for monitoring the activity of each of the gaming 
devices connected thereto and reporting this activity to the database 32. 
In addition, the floor controller is responsible for transmitting a 
reconfiguration command to a selected one or more of the gaming devices 
during cerUin bonus conditions. These conditions will be described m 
detail in the operation section below. 

The floor controller is connected to the associated gaming devices by 
current loop networks. Because of the limitations of the current loop 
network, only a predetermined number of gaming devices can be 
supported on any one current loop network. In the preferred 
embodiment, each current loop network supports up to 64 gaming dev.ccs. 
In order for each floor controller to support more than this prcdctcrmmcd 
number of gaming devices, each floor controller is equipped with a 
communication board 246. as shown in FIG. 12. Tl^e communication 
board 246 supports up to 16 separate current loop networks. The board 
is a stendard size card that fits into one of the ISA card slots in the back 
of the floor controller. The beard includes a male edge connector (not 
shown) which mates with a female back plane connector (not shown) in 
thefloorcontroller. The backplane connectorprovidesth^floorcontroller 

CPU daU. address, and control lines to the communication board 246 to 
enable the communication board and the floor controller CPU to 
communicate. 

The communication board 246 includes eight separate 
microcontrollers 248A.248H. The microcontrollers communicate with the 
floor controller through ISA bus interface logic 247 over buses 249A and 
249B. The microcontrollers are shown in a daisy-chain connection in FIG. 
12. but any other equivalent interconnection scheme can be used. The 



data received from the ndor controller microprocessor is passed between 
Uio microcontrollers from 248A to 248II. as indicated by tlic arrows. Rach 
microcontroller ia responsible for passing the data along and determining 
whether the data includes a message for a machine connected to its 
corresponding eurrent loop networks. 

Each microcontroller is responsible for two current loop networks. 
Each microcontroller communicates with its associated gaming devices 
via two corresponding current loop networks. Two serial signal lines 25 1 
connect each microcontroller to a current loop driver circuit 250. The 
driver circuit 250 provides the necessary current drive to support the 
current loop network. Each pair of serial signal lines 251 has a 
corresponding pair of current loop lines 253. The current loop driver 
circuit 250 can either be located on Uie communication board as shown in 
FIG.. 12 or on a separate printed circuit board (not shown). If located on 
a separate board, the current loop driver circuit 250 can be connected to 
the communication board by a cable. 

In the preferred embodiment, the last microcontroller 248H is solely 
responsible for communicating with the floor controller microprocessor. 
All of the data received from the machines over the various current loop 
networks are passed along to the microcontroller 248H by the associated 
microcontroller. The microcontroller 248H analyses, the data and 
determines whether the data needs to be communicated to the floor 
controller. If not, thelast microcontroller records the communication but 
docs not forward the data to the floor controller. This helps on--load some 
of the floor controller communication processing to the communication 
board. 



m. (oriHimniroiiH 

The above-described system allows a casino in which the system is 
installed to run promotions on any properly equipped gaming machines 
while simultaneously gathcringplayertrackingand accounting data from 
all machines. The system provides the capability for the casino to select 
which of the plurality of machines are used in any given jjromotion. The 
system furtlior allows any number of difTcrent promotions to operate 
simultaneously. 

Each promotion involves sending a reconnnuration o<>iiiiu:in<l I'rom 
the floor controller to a gaming device that has been selected U» bo part 
of a given promotion over the associated network. Upon receipt of the 
reconfiguration command, the gaming device reconfigures its payout 
schedule in accordance with tlie received reconfiguration conunand. As 
described above, reconfiguring a gaming device payout .^ch^!^Iul«. in the 
preferred embodiment, includes activating a bonus payout scluMluh! that 
pays out lx>nus amounts in addition to the aiu»>»nt d«!terniin«?d by the 
device payout table. 

A partial list of the promotions according to the inv»:ntion include, 
but are not limited to: a multiple jackpot wherein the gamir»g device 
reconfigures lis payout to be a multiple of iUs default payout scIumUiIi!; a 
bonus jackpot wherein the gaming device reconfigtuiw itsjiayout scluidule 
to pjiyout an additional bonus amount when certain conditions are niet; 
antl a progressive jackpot wherein two or more ganiing devices are 
ounbined in a progressive jackpot having a prui-rnssivo jackpot payout 
schedule. In addition to these, many other prontotions are possible by the; 
above-described system for controlling and monitoring a plurality of 
gaming devices. 

The system 10 also allows for iuiprovod playrr trarkiiig. As with 
standard player tracking, the above-described system MHUjitiirs and 
reports how many coins are played by eaclj player. Tlu; .sy.sten» 10. 

37 



however, also includes the abilily to record how long each phiycr speiuLs 
at each machine and the number of coins won« games played, and hand 
jackpots won by each player. All this information is stored on the 
database, which can be later analyzed Tor future targeted direct mailing 
campaigns. The player tracking according to the invention also allows 
the casino to schedule buses and other groups and mcasnro IhrAr 
prontability. The system also allows Tor cashless play as wcli as advanced 
accounting and security features. 

Another feature of the above-descrihod sy.stijm i.s jackpot 
announcements. The jackpot announcement feature displays a me.s.saf;o 
on a reader board or display located in the casino which announces a 
jackpot as soon as a jackpot is won, i.e., as .soon as the reels sLops|)innin^^ 
The Poor controller generates the jackpot announcement oiivv a DCN 
ci)nnf!cted thereto indicates a jackpot is won. An irxainpiir of .such a 
Hie.s.sai:e nn'nlit he: "Now paying on machine MW., a jackpot of $:i(H)." 
With prior art data c<illection Kysti*ni.M, tin? amount «>r tin* j:irkpot is only 
known after the payment iK matle, Kvrn then the .systrni nnist account 
for partial pays, hopper empty, etc. 

An advantage of the currc^nt system ovirr prior art systrin.s is Mii? 
ability to implenutnt better lournami?nt systitm.M. In a slot toiiriiainriiL, 
playcirs pay a fee to play. All phiy during the se.ssion is fri/r. Tin? play<>rs 
accumulate crediLsinstead of cash. The person with tin? nuist credits at 
the end of the tournament win.s. (]ames are ii.sually manually allrnsl to 
provide payouts of 200 to :»)()% to maki* Ihr i:ann«:i nnin* fun. Tin- ^ann'S 
are altered manually by repbicing the read only nnrnnuy (|{C)M) in Mn- 
gaming devtce.s. 

One excitini; asprct of tourn:uniM)t play i.s to nor who is ahrad. No 
curront sy.stc!m can display tlii.s information in rral tinn*. Tlii:: i.s hrcau.sr 
current systems can only measure winninns as thny an- addrd l.o (he 
credit meter or paid from tlie hopper (.some casinos us<? lournamcnt 



tokens instead). Since credits arc usually added a rate of 10 pur 
second, a 1,000 credit win can take 100 seconds to register. Casinos 
attemptine to create display boards showing who is ahead are frustrated 
by tl»e lag time. Hie jackpot announcement of the invention allows 
casinos to display the player with the mo.«;t credits by coinparini; the 
number ef credits for «»».ch player, llus comparison and display is 
perrormed real time as each transaction is completed. 

In order to implement each of tliese features, the various coinpuUjrs 
and microcontrollers each execute soaware or firmwan;. This soawans 
and firmware routines arc described below. These routines are clescrihcd 
with reference to accompanying flow charts. These flow diarts would 
enable one of ordinary skill in the art of computer pr«i:rainnnnj; to write 
n(!orrcs|)ondinE computer procrani which the computer or inimimntroller 

could execute. 

A. DATA COMMUNICATION NODK 

1. POWKK Ul» I'UOCKDUUK 

Iterurrini; now to FlCl. 13, u powttr up prorcdure 2rt'.l t'>f tUf «latji 
cM.inmnnirntion nodo in hIiowh. TIuh piowdure Im nxiMMitird l.y llii! DCN 
controller 40 when initially powered up. Tin? CuiiL iili?p «»f tin* pit.rr«lnn' 
ill 1.1 vali«5alo the IIAM to enuure lluit it in not « «»ri upti-il and In sn-t up all 
the DCN hardwaro. Vali«latinK the liAM involv.ra wrilini: Known p.iMi-rnH 
of In and Oh to tho 1)C:N KAM. 'rinM ItAM can either l.<! inln nnl to the 
DCN tontroller A2 or external as shown in KKJ. Settinc np Die DCN 
hardware incluilen initiali/.ini; tiniera and inlirri n|»lii. 

Next tho DCN c<>ntrolIer dieclui the liAM in step Ii.v n ailin/: Mie 
paltoni of 111 and Oa hack out of Hat ItAM tu ennin e that l UAM itt I nlly 
lunrtional. If tho HAM turna out to he defective the D« 'N .•..nl.n.lli r i-jm-.s 
into an endleiiH loop in 'JLMi. 



2. READING UNIQUE IDENTIFICATION NlJMnKIt 
If the RAM is fully functional, the DCN then reads the unique 
identification number from the. personality board. As described above, 
this unique identification number is stored in a nonvolatile memory 210 
on the personality board. Reading the unique ID number out of the 
nonvolatile memory involves following the memory manufacturer's 
interface protocol as specified in the nonvolatile memory data sheet. The 
unique identification number provides a means for uniquely identifying 

the gaming device. 

After the unique ID has been read from the personality board, the 
DCN processes the discrete machine inputs in step 260. This step will be 
described in further detail in Subsection 3. MONITORING GAMING DEVICE 
DISCRETE INPUT below. After the discrete inputs have been processed in 
step 260, the DCN processes the machine serial interface in step 262. 
This step is described further below in Subsection 4, PROCESSING GAMING 
DEVICE SERIAL INTERFACE. Next, the DCN processes the network 
interface, i.e.. the interface between the DCN and the noor controller 
connected thereto. The proces.<5 network interface step 264 is described 
further below in Subsection 6. PROCESSING NETWORK INTERFACE. Finally, 
the DCN processes the player tracking interface in step 2G6. This step is 
described below in Subsection 6. PROCESSING CARD INSERTION. At the 
completion of step 266 the DCN loops back to step 260 and continuously, 
sequentially executes steps 260-266. 

3. MONITORING GAMING DEVICE Dl.SCRETE INIHJT 
Referring now to FIG. 14, the DCN step of nu;...torinR Lho gaming 
device discrete inputs 260 will now be described. The DCN first rends the 
discrete inputs on input lines 76 in step 267. One particular set of 
discrete inputs is shown in FIGS. 4 and 9 for a particular gaming device. 
The actual discrete inputs present will depend on the machine type, as 
indicated by the configuration number. whici> is also read by the DCN 
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controller 46. Most gaining devices provide at least sonic of the following 
discrete inputs: coins in, coins out, coins to drop, games played, attendant 
paid jackpots, slot door, drop door, progressive jackpots, and bill 
validators. The system supports all of these discrete inputs as well as 
others. 

The DON keeps track of the machine activity by maintaining 
several meters in memory. Each meter, in the preferred enibodiment. 
includes six digits. Moreover, to improve the reliability of the system, 
the DCN maintains redundant backup copies of these meters with an 
order to replace the original meters in the event that the originals are 
corrupted. In step 268, the DCN increments the meters as required based 
on the discrete inputs. The meters are maintained even in the event that 
the DCN is disconnected from the floor controller. Once the DCN is 
reconnected to the floor controller, all the activity level information is 
then available. Step 268 will be discussed further below. 

Next, the DCN processes the drop door signal in step 270. The drop 
door signal DROP DOOR indicates that the drop door on the machine has 
been opened. This is an important event and is therefore processed 
separately. 

In step 272, the DCN validates the meter values to delcnnine 
whether the values stored in the meters are valid. The DCN checks 
whether the meter values are valid in step 274. In the preferred 
embodiment, a check sum is maintained for each meter value. Thus, the 
DCN in step 274 checks to see whether the check sum is correct based on 
the current meter value. If the meter values are okay, the discrete input 
monitoring step 260 is complete. If the meter values are not valid, the 
DCN replaces the meter values with the redundant back copy of the 
meter values in step 278, and then the step 260 is complete. 

Referring now to FIG. 15, increment meter step 268 is shown in 
further detail. The sequence shown in FIG. 15 is repeated for each meter 
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value that has changed. The first step is to adjust the meter value based 
on the discrete inputs and to calculate the associated check sum. Next, 
the DCN determines whether the particular meter has an active 
associated countdown count in step 282. Some games or promotional 
activities require the player to reach a certain level of activity in order to 
be eligible for certain bonus points. These countdown counts arc used to 
determine whether the player has achieved this level of activity. For 
example, the player may be required to play a certain number of coins 
before being awarded any points. If the countdown count is active, the 
DCN adjusts the current players count down values in step 284 based on 
the corresponding adjustment of the associated meter. 

In step 286, the DCN sets the current message to the count down 
message. The count down message indicates to the player when he or she 
will be eligible for the boniKS points. Finally, in step 288 the DCN sets the 
current bezel color and rate to a count down color and rate. This color 
and rate information is subsequently transmitted to tlie player tracking 
node for processing, as described further below. The countdown color 
indicates the bezel color and the count down rate indicates that flashing 
rate of the bezel color displayed during the count down message. 

4. PROCESSING GAMING DEVICE SERIAL INTERFACE 

Referring now to FIG. 16, a process 202 for processing the gaming 
device serial interface is shown. The serial macliine interface 60, as 
shown in FIG. 2, allows the DCN controller 46 to communicate with the 
gaming device through the personality board. This .serial machine 
interface allows the DCN controller 46 to tran.«;n)it reconfiKn ration 
commands to the gaming device in order to reconfigure the payout 
schedule ofthc machine in accordance with the reconfiguration command. 

In addition, the serial machine interface provides an additional means for 
determining the activity level of the gaming device. Instead of reading 
the discrete machine inputs, the DCN controller 46 can transmit a status 



request command to the machine over the scrini interface and the 
machine can respond back with the requested status information. 

Any communication protocol can be used to implement tliis 
communicaUon path over the serial machine interface, as is known in the 
s art An example of one such protocol uses a data packet including a 
command code, a message sequence number, a CRC, and a variable 
length message. In the preferred embodiment, either the DCN controller 
46 or the machine can initiate communications over the serial machine 
interface. However, if Uie machine detects that the DCN is trying to send 
10 a message to the machine, the machine must abort its message and 
'•I* attempt to resend the message at a later time. 

• **" The preferred embodiment of the system supports many different 

reconfiguration commands. A partial list of the reconfiguration 
commands is given below irt Table 1. These reconfiguration commands 
IS are sent from the DCN controller 46 to the machine over the serial 
machine interface wherein the machine reconfigures its payout^chedule 

• ••• 

• in accordance with tlie particular reconfiguration conmiand. The 

J reconfiguration commands do not originate with the DCN, instead the 

reconfiguration commands originate from the floor controller and are 
20 transmitted to a particular machine over the associated current loop 
I'll* network or the command can originate at one of the other computers on 

' • the high speed network. The DCN is simply responsible for forwarding 

the reconfiguration command onto the gaming device on receipt of the 
reconfiguration command over the associated current loop network 
25 coupled between the floor controller and the DCN. 

Table 1 -- Examples of Reconfiguration Commands 

1. Bonus Pay From Hopper (Coin Format) 

2. Bonus Pay to Credit Meter (Coin Format) 
30 3. Bonus Pay from Hopper (Dollar Format) 

4! Bonus Pay To Credit Meter (Dollar Formni) 
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5. Add Non-cash outablc credits lo Game 

6. Begin Double Jackpot Time 

7. Stop Double Jackpot Time 

The actual process of processing the machine serial interface begins 
in step 292 wherein the DCN polls the machine to determine its level of 
activity. This polling step includes sending a status message from the 
DCN to the machine over the serial machine interface. In response, the 
machine will send a packet of status information indicating the current 
amount of activity on the machine. The status information included in 
the response will depend on the type of machine that the DCN is 
communication with. 

The data communication node 42, in step 294. waits for a reply to 
the status request. If a reply is received, the DCN indicates that the 
machine is "on line" in step.296 and processes the machine reply in 298, 
The step of processing the machine reply includes updating the meter 
values, as done when processing the discrete inputs. After the machine 
reply has been processed, the process 262 is complete. 

If the DCN docs not receive a reply from the machine in stop 294, 
the DCN indicates that the machine is "onTline ". The DCN will wait for 
a predetermined amount of time before deciding that the reply is not 
received. In the preferred embodiment, this predetermined period is 
approximately 110. milliseconds. 

5. Processing Network Interface 

Another step in the DCN power up procedure 252 is the step of 
processing the network interface 264. This step is described with 
reference to FIGS. 17-19. The network interface refers to the current loop 
that connects the particular DCN with the as.sociated floor controller. 
The following description assumes that the DCN has received a valid 
message from the associated floor controller. Because there are multiple 



DCNs connected to any one current loop, the floor controller miist includo 
some means for addressing a particular machine. 

Although each machine includes a unique identification number 
which could be used as the actual address for each DCN on the current 
loop, it is unnecessary to use the unique identification as the actual 
address because there arc only a limited number of DCNs connected to 
each current loop. Accordingly^ in the preferred embodiment of the 
invention, the floor controller uses a shorthand token representation of 
the DCN's unique identification number to address the DCN. In the 
preferred embodiment, a single byte address is used to address a DCN on 
any^ven current loop. This one-byte address allows up to 256 DCNs Lo 
be supported on any given current loop network. In the preferred 
embodiment, however, only 64 such DCNs are connected to a single 
cur.rcnt loop and therefore4.he single byte address is more than adequate. 
The single byte address substantially reduces the amount of trafTic on tlic 
current loop network by reducing the number of bytes from four in the 
unique identification number to one for the 'shorthand token 
representation. 

The floor controller is responsible for generating the unique single 
byte address for each data communication node on a given current loop 
network. The process of assigning unique single byte addresses to the 
DCNs is described below in Section C. 

Once all the DCNs have been assigned a unique address, the DCN 
can begin monitoring the current loop network for messages addressed to 
it. If the DCN detects a message addressed to it, the DCN executes step 
264. The DCN first checks to see whether the message is valid in step 
304. This check is done by computing the CRC value of the message and 
comparing it to the CRC included with the message. If the two CRCs 
match, the message is valid and the DCN processes the network message 
in step 306. Processing the network message is described further below 



with reference to FIGS. 18 and 19. Once the message has been processed, 
the DON sends a reply back to the floor controller over the current loop 
network in step 308. The actual substance of the reply will depend on the 
message received in step 306. If the message is invalid, the DCN docs not 
reply. 

Referring now to FIG. 18, the first step of processing the network 
message is to determine what type of message was sent from the floor 
controller in step 312. There are three basic types of messages that the 
floor controller sends to the DCN. The first is a request for data from the 
DON. If this type of message is detected the DCN builds the data 
requested and transmits the data in a reply message. The main use of 
this message type is to gather status and meter information from the 
DCN. 

Another type of message is one including configuration data for the 
DCN. This message allows the floor controller to implicitly set the DCN's 
memory to a fixed value. This message is used to override the DCN*s 
internal variables, e.g., to get a DCN out of a lock-up condition, or to 
download new firmware to the DCN for execution. On receiving this type 
of message, the DCN simply overwrites its memory with the configuration 
data included in the configuration message in step 316. The DCN then 
builds an appropriate acknowledgment and transmits this 
acknowledgment. message to the floor controller in step 320. 

The other type of message is one sent in response to a DCN request. 
The DON. processes this data in step 318, which is described further in 
FIG. 19. If the message includes either the configuration data or the data 
in response to a DCN request, the DCN builds an acknowledge mossagc 
in step 320 and transmits this message to the floor controller. 

The step of processing a floor controller message sent in response to 
a DCN request will now be described with reference to FIG. H). The first 
step of processing this type of message is for the DCN to determine what 



type of daU is included in the message. Once again there arc three types 
of data that can be included in this message type: a reconfiguration 
command^ card data, or other minor data. The DCN makes tins 
determination in step 324 by analyzing one of Uie by tcs in the data packet 
ofthe message. This byte will be referred to herein as the command byte. 
If the command byte indicates that the message contains reconfiguration 
data, i.e., the command byte equals a reconfiguration command, the DCN 
stores the reconfiguration data in a predefined data structure in memory. 
Listed below in Table 2 is an example of a data structure for storing the 
reconfiguration data. 

Table 2 - Reconfiguration Data Structure 

1. Bonus Type 

2. Mystery Jackpot Data: 

A. Number of coins to award 

B. Number of seconds to award 

C. Pay award to 

3. Bonus Time Data 

A. Jackpot Multiplier 

B. Jackpot Payout Limitations 

C. Number of Seconds to Keep Bonus Time Active 

D. Minimum Activity Level 

The bonus type field of the data structure indicates the type of 
bonus state the machine is to be placed in. Examples of potential bonus 
modes include progressive/nonprogressive. multiple jackpot, or mystery 
jackpot. If the mystery jackpot is indicated, tHe mystery jackpot data 
included in the structure specifics the conditions under which the 
mystery jackpot is paid out. The mystery jackpot can be set to payout, 
e.g., afi-er a certain number of coins in, handle pulls, which is specified by 
subfields of the mystery jackpot data. 

The bonus time jackpot is a promotion wherein the machine pays 
out more than that dictated by its default payout schedule. In one 



embodiment of the bonus time promotion, the payout sch«d«l« of the 
machine can be modified to bo a multiple of its default to payout sclicdule. 
as specified in subfield (A) of the bonus time data. This promotion can be 
used to encourage gaming activity during off-peak hours, e.g.. midnight 
to 4 a.m. on wccknights. Alternatively, the bonus time promotion can be 
activated on a random basis. The timing of the multiple jackpot is 
specified by the casino on one of the computers connected to the network. 
The bonus time data also specifies the conditions under which the player 
becomes eligible for the bonus time jackpot. The subfield (B) of the bonus 
time data specifies whether the player is eligible for the bonus time data 
only if the player is playing the maximum coin in the machine. Subfield 
(C) limits the bonus time promotion to a predetermined number of 
seconds. This field limits the bonus time promotion to a predetermined 
number of seconds; if tlie player does not hit a jackpot within this 
specified time period, the bonus time promotion concludes. The minimum 
activity level can also be specified in subfield (D). This field can be used 
to specify the minimum activity level required by the playcr in order to 
be eligible for the bonus time jackpot. For example, the player can be 
required to play at least 20 coins over the last three minutes in order to 
be eligible for the bonus time jackpot. An indicator light on the player's 
machine can be used to indicate when the player reaches tlie minimum 
activity level and thereby becomes eligible for the bonus time jackpi.t. 

In another embodiment of the bonus time promolion. a bonus 
amount is awarded in addition to the payout according to the default of 
the payout schedule of the machine. The amount of the bonus jackpc.t is 
specified in subfield (E) of the bonus time data. For example, this bonus 
time promotion might include five bonus amounts of $10. $25, $50. $100 
and $500, which is specified by subfield (E). When a player hits a 
particular jackpot, whichever bonus amount is specified by the bonus 
amount subfield this amount is automatically paid out in addition to the 
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payout amount determined by the machine's default payout schedule. 
This bonus time promotion can also be used in combination with subr.clda 
(C) and (D) to specify the conditions under whidi the player is eligible for 
this bonus time jackpot award. 

After the DCN has stored the reconfiguration daUi in stop :r2G. the 
DCN will then send the appropriate reconfiguration conunand to the 
machine over the serial machine interface in step 328. The machine, 
responsive to the received reconfiguration command, reconfigures its 
pnyout schcdulo in accordance with the received reconfiguration 
command. For example, if the reconfiguration command specifics a 
multiple jackpot condition, the machine will reconfigure ils payout to be 
a multiple of its default payout schedule. The machine will reconfigure 
its payout schedule in a similar manner for the other bonus types. 

The other type of dataTthat can be included in a rcspon.sc from a 
DCN request is card data or player tracking data. This data is sent to the 
DCN in response to a sUtua message from the DCN to the Hoor controller 
wherein the status message indicates that a player card has been 
inserted. Included in this message is Uie card ID number detected by the 
card reader. In response to Uns status message the fioor controller will 
transmit a card insertion message to the DCN. The card insertion 
message includes information associated with the particular player ID 
number. An exemplary card insertion message data packet is listed 
below in Table 3. 

TABLE 3 - Card Insertion Message Data Packet 

1. Card Identification Number 

2. Player First Name 

3. Player Last Name 

4. Current Point Balance 

5. Casino Code 
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Upon receipt of the card insertion message, tho DCN stores tlie 
player's name and points in order for this inforination to he displayed on 
the VFD display associated with the player tracking node. Then, a DON 
sets the current message to a data received message in stop 334. Finally, 
a DCN sets the current hezol color and hczcl rate to a <Iata nscoiviMl be/.ol 
color and bezel rate in step 336. The bezel color spocines tl»c bezel color 
to be displayed by the card reader and the bezel rate specifies the (lashing 
rate of the card reader LEDs. This bezel information is subsequently 
transmitted to the player tracking node for processing thereby. 

The final data type that can be included in the message sent from 
the fioor controller in response to a DCN request is generically classified 
as otlier minor data. This data includes general system or DCN specific 
information such as display information. 

6. PUOCESSING PIAYKU TllACKINO INTKIIFACK 

The next step in the DCN process is processing of tlie phiyer 
tracking interface 266. The DCN maintains a variable that, indicates 
what message is to be sent to the player tracking node. This variable is 
referred to as the current message variable. Before Iransmitting a 
message to the player tracking node, the DCN first checks this variable 
to see which of a plurality of messages should be sent to the player 

r 

tracking node. 

The process 266 begins in 340 by sending the current message to the 
player tracking node that is specified by the current mcs.sage variable. 
In addition to the current message, the DCN sends the bezel color and 
bezel rate information to the player tracking node. The bezel color and 
bezel rate information could have been specified by the fioor controller or 
by the DCN itself. 

Next, the DCN determines the card status in step 342. If there is 
no card inserted in the card reader, the DCN sets the current message 
variable to on attract message. This message specifies that the player 
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,„„c1,ino. Simil«rly. U,a nCN »ct3 the current l««el cW .nd tol raU, 
lo an allracltezol «,lor and rate in .Up 346. -n.ia attract calor an.l raU, 
i, part orihe attract .nosaa«c that will l« «nt to tl.c play.,r IrackinK n«.l« 
wIhmi LIh! rurnjul iiwKsai'o ih 8«nt. 

If ll„. DCN dclcr..u««« ll«.t « Kood '"'""''"'^ 
can! .cndcr. the DCN processes the valid card in «Um> :ir.». MIuh Htep is 
described further below with reference U. FIG. 21. 

If however, the card st:.tus indicates that a bad card has been 
i„Hc.rted. i.e.. an invalid card nundu^r. the IXJN se-ts the current nu..«n,,e 
variable to specify a card error „« in nr.. an,l the DCN sets the 
current bezel color and bezel rate to « card error color and rate n. 
This card error infornuaion is included with the card error .nessa.e that 
is sept to the player tracki.VK node when the current n.essa,.e is sent. 
7 niOCKSSlNd CAllI) INSKUTION 

Referring now to FIG. 2 1 . the process 350 for processing a valid card 
U,^,nUm i« .hown, Th. Hr^t «U,„ that th. PC^N executes i.s to .H.tenni.^^^^^ 

from the floor controller in step 356. If not. the DCN builds a network 
request message for the player name and points associated with the card 
ID number in step 358. Next, the DCN sets the current message variable 
to specify a card inserted message is to be transnntted in stop 300. 
Finally the DCN sets the current bezel color and rate to a card inserted 
color and rate, which indicates to the player that the system is st.ll 
processing the card number. This information is sent t.. the player 
tracking node when the current message is sent. 

If the card data has been received from the floor controller, the DCN 
then detennines in step 366 whether player tracking has started for the 
particular player. If player tracking has notyetstarted. the DCN sets the 
current message variable to the data received message in step 368 and 
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s«ts Ihv. current l»«7.«I color and rale to data nrc,Mv.«l color and . a U- i.. sL p 
a70. If player IrackiniJ h«H sUirU-d. the IMIN procoKS.'.., the playt r 
tracking in step 372. na described with reference U» KHJ. 

|»r.K:eH.sin« phiy«r tnickim; 372 iM^ns with th« si-.. or.lrU j nu..in« 
wiMalHtr the player han rm:eiv,!«l new iM.intH in .T/l. TI»-.;.. pninl:. ran In- 
.:n„Hi.l«HMl rouuhly a., the .^p.ivaloat of "fn^patnt lly. r nuhv." ..». d hy 
airlinoH. 'nicfio pointH aUow the syaUnn to run pronu.lional:. wh. n hy 
i,„r. vi.hialH are Kiven poinU or credit H«H.«:iaU«I with th.rir rard that ran 
Imj nrd««MU«.l U.war«l th« purchaiMJ «ri:.HMhi or si rvirrs oiT. r.Ml hy th.- 

oaHino. Typically thei.« poinUi are redeijni.Ml at a nMlrn.pl. o....!.-. in 

Iho cuHii.o for luoah. or d.ahin,:. Cor ex»...pl.v Tl... pninlM. tl..-. ..lo. ... an- 
an additional induc«;nn:nl to encourai;.! play. 

The player tiackint: nyi.l.;m of l\u>. ii.v.-ntio.. alh.ws tl... . asino to 
,lot.*nni..« how aind when tj.e ph.yor \h i.nsu.Ml poinL.. Th.- ra.si.... . a., 
specily the type and .unnhor of coins that niust I... playrd M\,n' a playor 
i.s owarded a uiven nu.nher of poioLs. The sysL.M.. ..s. s this »p. rilMrd 
inr..rniati«n to inforn. the player of his or h.M ,..or.n»M «..w:ud.-; l.. ..ivi,„; 
o.hlitioiial poinU.. Tl.o aysitiMU e..ro..rai;fM play hy inl... mine I h- playi r 
oria.w many additional coins nn.st he pla.y.rd h..!.... • . . vin,: ..»l.lilional 
poh.ts. For exan»ple. a playor who is only uno min aw:.y l.u.n .. . . ivh,,: 
points, hut wl«i desires to stop playinj;. may d.rci.l.^ U. play "...nr h«»t 
in order t.. reaiive the points. The syslcn. in[»..n.s Mm' vhxyrr hy 
displaying a niessaKo on ll.e vacuum lloresceiit display i.nlicatinr. hnw 
nvany coins. the player is away fiwn receivini: ad.liii..Mal p..inl^;. 

Referrin,; now to .C. 22. player trackini: :»72 h-Ki-s with ll... sl.^p 
ol detennininu whether the player has rec»!iv«Ml ... w p..inl:; in :rM. 11. .o 
new points have Iieen received, the IX:N .s..Us the c.rnrnt .n..ssai:.5 
variable to specify a countdown message in sUm» 370 an.l sels the curnMit 
bezel color and bezel rate to a countdown bezel color and i alo in sl..p 378. 
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Tho countdown bezel color ;uul rale imllcates the player's pmnresM 
lowarcKs licing awarded additional points. 

If new points have been received, siidi as where tlie player has 
played 11 Kivcn number of coinH, the DCN sets th.5 current ineHHn/:e 
viiriahle to ti |M.inis v/on nieHsai'r in step IW.* and mtts the rurnrnt lirzi l 
«>lor and rate l« a points won color and rale in step .IH I. 'Hie p"««'t:' won 
message inforntH Uh? player of the nundier of points won. 

TIm! nbovn-deMcrilMMl trai.kini; pnurnfw pnividi-.s a ni«;:in:i t'nr 
providini; vinual feetlbaek to the play.-r inni-rtinjt H"' «-.«td into Ihr ( aid 
rea»ler; Uy niodifyinii the iMtzel color ami hi wl t»U', Ihr .lain 
conuMunication noile provides inuiiediale ferdl.ark U* ihe play.^r 
conrernin. : the proper inserti.in of the card. If the play«!r inserLs the card 
pmiMJrly inU» the card reaider so that the card reader Hen.nes a valid user 
identrlication number, the cani readier provides positive vi.'iual feedback 
to the user by illuniinatini: the b.!/.el. On the ..ther hand, if the u::tM- 
improperly inserLs the card so that the card reader cannot read the u-sirr 
identillcation nundwr. the card reader can pnivide nci:ativr vi.iiial 
fiMMlback to the player by illuminalinit the Im'/.i-I wilh a dilfrient color 
and/or llashlni: rate. In the preferred einliodiinent. this pnsitivc vi.mal 
feedback inclmles Clashini' the r.nten I.KDs to produce a na.-£hiiii: r.« «•«*«« 
signal around the canI reader openini'. The negative visual feedback 
includes IlashinK the red hUDs. A thini combination color h: u.m-iI dui inj: 
the proce.ssim;of Ihe player trackinji information. This process provides 
immediate feedback to the player coiiceniini: the iii::i tlion of llie card in 

the rani reader. 

l\. IMJVYKKTKACKINtJ MODUl.K 

Tlie system describiMi above allows for improved player Irackini' by 
niconliiii: each and every machine transaction includini:: lime of play, 
machine number. <luration of play, coins in, coins out. hand paid jack pots 
and Kaine.«5 played. The player tracking is conducUul over the same 



network as the accounting data is extracted. This allows the invention to 
provide bonusing to certain individual players as well as during certain 
times. As with standard player tracking, the above-described system 
monitors and reports how many coins are played by each player. The 
system according to the invention, however, also includes the ability lo 
record how long each player spends at each machine and the number of 
coins won. games played, and hand jackpots won by each player. The 
system is able to record all this information because the it operates on a 
transaction by transaction basis. Each transaction, whether it be a coin 
in. a handle pull, etc., is recorded by the system. Other prior art systems 
simply compile the player tracking information at the completion of play. 

All the transacUon information is stored on the database, whicli can 
be later analyzed for future targeted direct m;«ling campaigns. The 
player tracking according to the invention allows tb.e casino to schedule 
buses and other groups and measure their prontability. Because the 
system records each transaction, the casino can reconfigure their casinos 
to better match the tastes and demands of Uieir customers. 

The improved player tracking according to the invention also allows 
the casino to calculate theoretical wins exactly because the system always 
includes the most current information. The operation of the player 
tracking procedure is described below. 

1. POWER Up Procedure 

The operation of Uic player tracking module will now be described 
with reference to FIG. 23 where the powerup process 400 for the player 
tracking node is shown. As in the data communication node, the player 
tracking node first validates the RAM and sets up its associated hardware 
in step 402. Next, the player tracking node tests the RAM in step 404 to 
determine whether the RAM is functioning properly. If not. the player 
tracking node. i.e.. player tracking controller, terminates its program in 
an error condition in step 40G. If the player tracking RAM is fully 
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functional, Uio player tracking node sequentially executes steps 408-414. 
In step 408 the player tracking controller processes the DCN interface 
between the player tracking controller and the DCN controller. In step 
410 the player tracking controller updates the player tracking display. 
In step 412 the player tracking controller updates the bezel. Finally, the 
player tracking controller processes the card reader in step 4 14. Each of 
these steps will now be described further below. 

2. Processing DCN INTERFACE 

Referring now to FIG. 24, the steps for processing the DCN interface 
are shown. First, the player tracking controller checks f. r a new message 
received from the DCN in step 416. If a new message has been received, 
the player tracking controller overwrites its current message bulTer with 
the new message and updates the bezel color and rate values witli those 
contained in the new cucrent message. Then, the player tracking 
controller builds a card status reply message in step 420. The card status 
message indicates whether a card has been inserted and if so whether the 
card was a good card or a bad card, i.e., the card was read properly by the 
card reader. If a valid card, the card status reply message also includes 
the identification number encoded on the card. Tliis step might also 
involve transposing the number encoded on the card depending on tlie 
orientation in which the card was inserted into the card reader. This card 
status reply message in then sent to the DCN in step 422. 

3. Processing DISPLAY Updatk 

The process of updating the player tracking display is shown i n FI G. 
25 at 410. This process begins with tlie player tracking controller 
scanning the display message for display attribute information. 
Examples of such display attribute information is given below in Table 4. 
Each display attribute specines a difTerent graphic mode for the player 
tracking display. 
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TABLE 4 - Display An'uiDLrrE information 



1. 


1711 ^^t* Dm^a 

Flash liate 


2. 


Center Display 


3. 


Set Display Intensity 


4. 


Use Small Lower rent 


5. 


Use Small Upper l* ont 


G. 


Use Normal Large ront 


7. 


Set Pause Time 


8. 


Set Scroll Speed 


9. 


Center and Melt 


10. 


Center and Scroll Down 


11. 


Center and Scroll Up 


12. 


Scroll Down and Stop 


13. 


Scroll UP and Stop 


14. 


Scroll Left and Stop and End of Message 


15. 


Scroll Down 


16. 


Scroll Up 


17. 


Scroll Right 


18. 


Scroll Left 


19. 


Reverse Video - 


20. 


Normal 



The player tracking controller then determines whether any such 
attribute information is found in the display message. If so. the player 
tracking controller sets up the display driver to incorporate the graphics 
mode specified by the attribute information. The player tracking 
controller then strips out any display attribute information from the 
display message in step 432 because the display attribute information is 
embedded in the display message. The remaining data in the display 
message is the actual text to be displayed by the player tracking display, 
e.g., the player's name. The player tracking controller then sends this 
t6xt to the display in step 434, which is then displayed by the player 

tracking display. 

4. Processing bezel Update 
The player tracking node is also responsible for updating the bezel, 
both in terms of its color and flashing rate. This process 4 12 is shown in 
FIG.. 26. The first step in processing the bezel update is to determine to 



bezel color as spccined by the DCN and then drive the nppropriatc LEDs 
in the card reader. As described above, the preferred embodiment of the 
card reader includes dual diodes having two primary colored diodes that 
can be driven separately or in combination to produce three different 
colors. 

Next, the process determines the bezel rate as specified by the DCN. 
In a first case, the bezel rate is zero or off and thus the player tracking 
controller turns the LEDs off in step 442 in this case. If U)e bezel rate 
specifies a flashing rate, the player tracking controller Hashes the bezel 
at the appropriate bezel rate in step 442. Flashing the bezel involves 
turning the LEDs on and off at the specified rate. This can be 
accomplished by a timer interrupt or a timing loop executed by the player 
tracking controller. The final option is that the rate can be infinite or 
effectively a solid bezel color. In this case, the player tracking controller 
simply leaves the card reader LEDs on in step 446. This completes the 
processing bezel update process 412. 

5. Processing Card Reader 

The next process step for tlie player tracking node is lo process the 
card reader. This process 414 is shown in FIG. 27. The first step is for 
the player tracking controller to determine the card status in 450. In the 
preferred embodiment, the card status is determined by comparing the 
checksum of the card, as read off the card by the card reader, to a 
computed checksum of the data read off the card. Other methods of 
determining card status can be used as well depending on the type of card 

reader employed. 

If the player tracking controller determines that a valid card was 
inserted in the card reader, the player tracking controller sets a card 
status variable equal to good card. This card status is then subscquenLly 
transmitted to the DCN controller. Then, the player tracking controller 
sets a card ID variable equal to the identification number read by the 
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card reader in step 454. The card status and tl»c card ID provide the 
DCN witli sufTicicnt information to instigate the player trnclting. 

If, on the other i»and, the card reader indicates that tlie card was 
read improperly or that the card is an invalid card for the card reader, the 
player irnckine controller sets the card status variable to bad card in step 
468 and Uie card ID variable is cleared in step 4G0. If neither a valid or 
invalid card condition was detected in 450, the player tracking controller 
sets the card status variable to noeard in step 462 and clears out the card 

ID in 4C0. 

C. FLOOR CONTROLLER 

1. powEtt Up Procedure 

Referring now to FIGS. 28-32, the process 464 operable on the Hoor 
controller will now be described. The process 464 is shown in FIGS. 28- 
32 in flow chart forms. These flow charts would enable one of ordinary 
skill in the art to implement the process in computer soaware using an 
appropriate computer programming language. 

The floor controller process 464 begins at step 466 by opening the 
database Ubles in the file server. As described above, the file server 
includes a commercially-available database program which stores the 
machine activity information as well as player tracking information and 
associated system characteristic parameters. This step 466 can also 
include fetching some or all of these system characteristics in order to 
trigger certain events such as bonus jackpots, as described below. 

In step 468, the floor controller terminates any active player 
tracking sessions in the database. Because player tracking may liave 
been in progress when the floor controller became inoperablo, when the 
floor controller powers up or becomes operable, there may be player 
tracking sessions initially active. In this step, the floor controller 
terminates any such active player tracking sessions in order to place Ihc 
database in an initial state. 
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Anolh«sr step that Uie floor controller executes aRer becoininc 
operable is to place an initial madiine search messnge in nn output 
message queue 470. This search message is used by the floor controller 
to determine which machines arc connected to Uie floor controller. This 
output message is subsequently transmitted to all of the machines 
coupled to the floor controller using a global message format, as described 
below with reference to FIG. 31. In the preferred embodiment of the 
invenUon, the message handling is through the use of message queues. 
Furthermore, the preferred embodiment is both an output queue for 
outgoing messages from the floor controller to the machines and an input 
message queue for messages coming from the machines to the floor 
controller. Queues are well-known data structures in the art of computer 
science and are therefore not further discussed herein. Alternatively, the 
message-handling could be 4one wiUwut the use of the queues. In such 
an embodiment the outgoing messages would be sent immediately rather 
than being queued, and any incoming messages would be processed 
immediately. 

The bulk of the work performed by the file server process 464 is 
performed in message processing step 472. In this step, the floor 
20 controller processes all messages sent to or received from the machines 
•it* connected thereto. This step will be described further below with 

references to FIGS. 29 through 31. 

The process 464 also includes a systom monitoring stop 474. This 
systom monitoring stop 474 administors certoin systom-wide events. 
25 These system-wide events include the counting-related events and 
bonusing events. The floor controller continuously checks to see whether 
any of these events have been triggered. If any event has been triggered, 
such as a bonusing event, the floor controller takes the appropriate action 
to handle the event The event may be triggered by the time and day or 
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by user intervention or 6Uier event. The system monitoring step 474 w,U 
be described further below with reference to FIGS. 32 and 33. 

The nnal step in process 464 is for the floor controller to check for 
a termination condition in step 476. In the preferred embodiment. U,e 
noor controller checks to determine whether an ESCape key .ns pressed. 
If an ESC key was pressed, U,e floor controller terminates Uie process 
464 If no ESC key was pressed, the floor controller loops back to step 472 
wherein the message-processing step and the system monitering step are 
repeated. The floor controller continues in the loop 472-476 unUl the 
termination condition is sensed. 

2. MESSAGE PROCESSING 
As described above, the floor controller acts as a gateway between 
the machines connected Uiereto and Uie file server, as shown in FIG. I. 
The floor controller is responsible for forwarding the machine acUv.ty 
received from the various machines to the database. The floor controller 
accomplishes this communication through the use of messages. 'Ihe 
message processing step 472 is shown in more detail in FIG. 29. 

The first step in processing the messages is for the floor conlroUcr 
to send any messages thatare queued-up in the output message queue to 
the appropriate data communication node in step 480. As descr.bed 
above, the output message queue is a simple daU structure that i.s used 
to store any pending messages. Included in the message is a destmat.on 
address by which the floor controller can determine which ofLbe pU.rnl.ty 
of data communication nodes to send the message to. Next the floor 
controller receives any incoming messages from the dnU communication 
nodes coupled to the floor controller in step 482. Once an inconnng 
message has been received, the floor controller parses through the 
message data included in the incoming message in steps 484 through 486. 
In the preferred embodiment, the floor controller parses through the 
„.essage data one byte at a time. Thus, in step 484 the floor controller 
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reads Uic next bylc in U»c incoininc message, and in slcp 48G Ihc noor 
controller checks to see whether Uiis is Uie last byte in the incssacc. In 
the preferred embodiment, the message includes a mcssngc lenglh field 
which indicates U»e number ofdaU bytes included in the mcssaKc. In 
this case, a floor controller in step 486 diecks to see whether the number 
of bytes read in slcp 484 is equal to U»e number of bytes specified by the 
message length fleld. 

Once the input message daU has been parsed out of the incoming 
message, the floor controller takes U»e appropriate match in response to 
the message daU in slcp 488. This step is described further below with 
reference to FIGS. 30 and 31. Following the message-handling step 488, 
the floor controller diccks in step 490 to determine whether any response 
is pending. The floor controller makes this detcrminalion by chocking a 
transacUons-in-progrcss structure which indicates whclher the floor 
controller needs to respond* to any previous message. If a response is 
pending, the floor controller queues up an appropriate outgoing message 
in the output message queue in step 492, Otherwise, the floor controller 
completes the message processing step 472. 

Referring now to FIG. 30, the message-handling step 488 is shown 
in more detail. The message-handling step begins by verifying that the 
message data corresponds to a valid message in step 496. In the 
preferred embodiment, the message includes a cyclical redundancy check 
(CRC) by which the floor controller can determine whether the message 
is valid or corrupt. Only if the message is valid will the floor controller 
perform any additional message-handling steps. The floor controller also 
parses through Uie message in step 496 to determine what type the 
message is. The message type determines Uie appropriate floor controller 
action. In the preferred embodiment, the messages include a command 
code which indicates the type of message. 
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The first type of messaeo can be one which indudes new meter 
information. The floor controller checks in step 498 to determine whether 
the message includes this type of infprmaUon. If Uic mcssace includes 
new meter information, the floor controller saves the new meter 
information locally in step 500. The floor controller maintains local copies 
of the meUr information in order to minimize the amount of trair.c on the 
high-speed network. Because the machine meters change so rapidly, 
forwarding this new meter information on to the file server each timcone 
of these meters is altered would produce an excessive amount of network 
tramc on the high-speed network. Therefore, in the preferred 
embodiment, the floor controller saves this new meter information locally 
in step 500 and only forwards the new information on to the file server 
atUsr a predetermined amount of time has elapsed. 

Another type of message is one which requests data. The floor 
controller checks in step 502 to determine whether the message type is 
one requesting data. Typically, these data requests will be for player 
tracking information such as where a player inserts a card info a card 
reader whereupon the data communication associated therewith sends 
the identification number encoded on the card to the floor controller 
requesting the player tracking data associated with the player 
identification number. If the floor controller detects a data request in 
step 502. the floor controller looks up the requested data in the database 
on the file server in step 504. Also, in step 504. the.floor controller marks 
a response pending in the transactions in progress structure to indicate 
that this requested data needs to be sent back to the DCN. As described 
above, the floor controller queues up outgoing messages responsive to the 
transactions in progress structure. 

Another message type is one used by the floor controller to esUiblish 
new machine addresses. The floor controller periodically checks to 
determine whether any new DCN has been coupled to its associated 
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current loop networks in order to assign a unique address to that 
machine. In step 506. the floor controller checks to see whether the 
incoming message is in response to such a process. If the incommg 
message is in response to a machine search, the floor controller assigns 
a new machine address to the responding machine in step 508. The 
entire process of assigning new machine addresses is described below 

with reference to FIG. 31. 

Finally, the floor controller in step 510 handles any miscellaneous 
messages. These miscellaneous messages are used primarily for 
debugging and trouble-shooting the machines. 

3. ASSIGNING GAMING DEVICE ADDRESSES 

As described above, in the preferred embodiment of the invention, 
the floor controller uses a shorthand token representation of the DCN's 
unique identification number to address the DON. In the preferred 
embodiment, a single byte address is used to address a DON on any given 
current loop. This one-byta address allows up to 25G DCNs to be 
supported on any given current loop network. In the preferred 
embodiment, only 64 such DCNs are connected to a single current loop 
network and therefore the single byte address is more than adequate. 
The single byte address substantially reduces the amount of trafTic on the 
current loop network by reducing the number of bytes from four in the 
unique identification number to one for the shorthand token 
representation. 

The floor controller is responsible for generating the unique single 
byte address for each data communication node on a given current loop 
network. The process 508 of assigning unique addresses to the DCNs on 
the current loop network is shown in FIG. 31. The process begins by 
defining a range of unique identification numbers in slop 512. Initially 
this will be a large range. 
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Next, the noor controller sends out a mcssngo to nil of the PCNs on 
the current loop network in step 514. The Hoor controller comntunicales 
with the DCNs by using a standard communication protocol, hi Uie 
preferred embodiment, this protocol defines a message format including 
a destination ID. a source ID. a message length, a data packet and a CMC. 
Other message formaU could be used as well. Using this format, the n<M,r 
controller can communicate with all of the DCNs on the current loop 
network by using a global destination address in the mes.snge. Th.s 
global destination address would indicate to the DCNs that this n.essagc 
is intended for all DCNs on the current loop network. Thi.s global 
me.,saBe would include two unique identification numbers that, taken 
together, define the range of unique identification numbers established 
in sU!|> 512. 

The individual DCNs then cliecks to son whclhor Ihoir ...u<iuo 
identification number falls within this range. If a DCN's unique 
identification number falls within this range and tl>e nCN docs not have 
«n address assigned thereto, the DCN then respcnds to this KU.l.nl 
message by sending a reply message in response th:.t includ.s Iho un,(,u. 
identification numbcrof that DCN. In the event that .noro than «n.= DCN 
has a unique identification number that falls within this range a network 
collision will occur and the message will be corrupted. TUo process 508 
checks for this condition in step 516. This condition is indicate by an 

invalid CRC in the message. 

In the event of a network collision, the fioor controller can linut the 
range of unique idenUfication numbers by repeating step 512 in the hope 
of eliminating this network contention. 

If the response has a valid CRC. the fioor controller assigns a 
unique address to the responding DCN. as identified by the unique 
identification number in the response, in step 518. The fioor controller 
then transmits this address along with the corresponding un.quc 
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idcntincation number in an assicnmcntmcssafic to all of the DCNs using 
o global dcsUnaUon address in step 520. The DCNa then process this 
mcasaeo and in the event thai the unique identification number included 
in the message corresponds to U»e DCN's unique identification number, 
the DCN ndopU U»o address included in the n.nssaK«. i )ncn tlu, I)( IN has 
been assigned an address in this manner, the DlIN will interpret all 
subsequent messages having a destination address equal to the assiuno<l 
DCN address as being directed to that DCN. The „bove-de.scribca 
address assignment sequence is repeated for each of the renuiining DCNh 
«„ the current loop network in stop 522. The n»..r c<H.tr«ller cntinues 
this process until thoenUrc range of unique identifiration nun.hon. has 
been covered and no more network collisions occur. 
4. SYSTEM MONIIXJUINC 
Uoferring now to KIG. 32, the iiyHteni nioniUuin,: sfp 474 will now 
hi! .loHcribcl. The lloor bontroller is now reM|H,nHihl« lor uiouiturini: 
CM tain sysUnn-wido conditions to detennine whether .terU.i« uventH ne.Ml 

to occur. The systoni monitoring slop also han«lles r.M|u.!sL H.r particular 
machine infunnation. Thus, in stop 524. the Ihu.r o.ntn.ller determines 
whether a new request has been placed in th.t .lata base for such 
particular nuichine infunnation. If such a request has been placed, the 
noor controller responds to the special request for data in stop 520 by 
.sending a message to the particular u.achine reipiesli..,: the re(piire.l 
information. Once the required inforn.ation has been receive.l. the ll.mr 
controller processes this information accordingly. 

The noor controller also n»onilors the locally-storiMl m.aer 
information in step 528. If the locally-stored information is chan,'.e<l. the 
floor controller saves the latost informaUou U. the data base in step rM). 
As described above, the fioor controller saves the meter inlbrn.ati<.n 
locally in order to minimize the trair.c to the file server over the hi,;h 
speed network. 
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The floor controller also nwnitora Iho system for certain event 
triKEcrs in step 532. These triggers can be stored in the tlsiU base and 
fetched by Uic floor controller during its power-up pniccdures. These 
triggers indicate if and when cerbin events occur. Examples of event 
s triggers include: the drop period, the end-of-day. the honn« period, etc. 
If an event trigger has occurred, the floor controller h.indles Uus event in 
step 534. 

The handle event step 534 is shown in more detail in 1<'KJ. 33. The 
events can basically bohifurcated into accounting «!v..nls and l«.iiusing 

10 events. Accounting events refer to the data coinniuni< at ioii .irtivily «.f the 
Byslem. The accounting evenU are typically triggered by a cnrtain time 
of day such as tbe end of day or the drop period. If an ac«:oimtinrt nv.int 
has been triggered, the door controller perfonns llu; n-.piinr.l .lati« basu; 
operations in step 538. 'Wiiu step involve.! npdatim: "H of llu- lorally- 

ir. HtoriMl meter infonnation ami iitoring the updated mi lirr inrorniation into 
Iho ilaUi bn.se. 

Tbe other tyi»o of event can be referred to a.s a bonnsing «!V<M»t. TUv. 
floor controller chiscks to ueo whether tim ovuiit \a a bnmi.sim: «^vi!iit in 
Htep 540. The Uinusing ovenU can also be triggered by l\w I'mw niMay. 

•20 For example, the bonuaing event may be trigjcered IVon» midnir.bt U. 

a.m. on weekdays. These Iwiiusing periods ran bo kp^m UlmI in Lb.- «lala 
base. If the triggered event is a l)onusing «!venl, IIh; Moor rontrolb-r 
inserts a corresiM.nding reconfiguration measagM in llin «»ul.pu«. inr!:.:ai:i« 
queue in. .step 542. The reconfiguration n»e.s.saj:o iiichitl.vi a 

25 reconfiguration command that is sent to an appropriate ma« bine. TIh» 
marhine. upon receiving the reconfiguration conun.Mnd. nc»nfignn«.s its 
payout schedule in accordance With the reiuiv.Ml nMnnru'iiraliuii 
command. According to the invention, there are many dillerenl 
reconfiguration commands to iniplement a nuiltiplicily of dimirent 

30 Iwnusing events. One reconfiguration connnand specifics that tlio 
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machine should rcconriKurc its payout schcduhj t» ho a .nultipic of iU 
dcrault payout schedule. This rcconfieuration command can also specify 
that the multiple payout sdicdulc should be lin»itcd to a prcdutcnninod 
perccnLacc oftlw coins in. This rcconfiKuration command can furlhor 
npocify that the nmltiplo payout schedule shouUl Im limitiMl t» only wh.u, 
the maximum coins are played. This reconriijun.tion conunan.I can 
further specify that the multiple payout schedule should he lin.iled to 
p„y„ula in a specified rontc. This rcconfiKuration cnunaiul can ;.l«o 
Hprrifv the nudlipio payout schedule should payout only wImm. ,. 
pnMlitlitnnined level ofidnyor acUvily in reached. 

Another reconlluuraUon connnand allows any nuinhrr of niachineH 
on the network to be combined in a conunou ja.:kp..t l.avi.,,: .. rounnoi. 
jnckpot payout nchedulo, wlwuein tl.n n.r<.nr.|:nn.l.i«.n ronunniui 
ii,in*nri|!ureH the selectod MUicliin<»i to payout in ,.r.:o,.l..i.r.. will, ll.v 
.•ouunon jackpot payout aoIuHlule. In Uuh .:;..wr. Uur n.rour.,...ui.!.ion 
mo.mai:« would Ih) <pi«wed up fur eucl. of Iho ..ohntlnd nu.. hiur.. to bo 
ron.bin.Ml in a connnon jackpot. One oxan.plo of a ro.nn.on jHrkpul i.i n 
proitrrimive jack|M.t. Unlike the pri..r art pio,:n.,...ivr ja, kp..l ..ynl...o«. 
|,owov.,r. the proitrofiiiivo jackp<.t».:c..nruu: to ll.o ii.v.M.lio,, in ....1 '....ilr.l 
|„ a predetermined nun.ber of nmcbinrM. In tbo i.rioi m l p. ....ivr 
jnrkpot iiyHtemii. a bank of niadiinea i.ro n.nn.-. U-.l I" i. . ..nunon 

pio|:n.imivoj»«kp«»t controller JUid only tb-i.e nii.rl.in..,! . 1... in. In. 

in Uio pr«,:re«Hiv« jackpot. In cnUaat. any uum biu.- .... II..- ... ixvo.K. 
•iicludini! thoae wmnected toother n.K.rcoiitr«II.Mnr:.M l.r . ...nUin.Ml iolo 
a connuon proKreasive jackpoL Moreover, the ...uub.-, ol pn.,..,r:.Mivr 
j:„ kpoiM ia lu.t limiUMl by the number of Ib^.r . onlrolbM :. -..mrr lloo, 
ronlroll«?r can nunun:e nu»re than one prni:rrHsiv«. j...:kpol. 

An..ther reconfiijuration ci.nuaand.pcru.itn tlu- »v»: riu U, i...pl. n.-««l 
.no-called "auUimatic mystery jackpoLs." These -niy.stery" jarkpoLs allow 
n machine to payout a mystery jackpot even whon a jackpot was not won. 



Instead, the reconfiguration command can specify that the mystery 
jackpot is to occur after a certain number of coins, a certain number of 
handle pulls, or a variety of other conditions specified by the 
reconfiguration commands. These mystery bonuses provide the casino 
with another way to induce additional gaming activity. 
5. BONUS CONTROL 

Referring now to FIG. 34, a method 550 for controlling the 
conditions under which the above-described bonus activities are activated 
is shown. It is essential for the system to have complete control over the 
amount and conditions under which a bonus is paid out in order to insure 
the profitability of the bonusing system. The method 550 described below 
provides the required control. 

The method 550 begins in step 552 by disabling or turning ofT the 
bonuses in the individual machines. This is accomplished by sending.a 
message to the individual DCNs to turn ofTor deactivate bonusing. Next, 
the Hoor controller monitors the activities of the individual machines 
connected thereto. This step includes monitoring the coins in and 
bonuses paid for the individual machines, as described above. In step 
556, the floor controller modifies a bonus pool by a prcdetcnnined 
percentage of all coins played. The bonus pool is essentially a pool of 
monetarj' resources that can be allocated for bonus awards. In the 
preferred embodiment, a predetermined percentage of the monetary value 
of the coins played are added to the bonus pool.. Also in this step, any 
bonuses paid by the gaming devices are also measured and subtracted 
from the bonus pool. The use of the bonus pool will become more 
apparent when the other steps are described hereinbelow. 

In step 558, the floor controller determines whether or not bonusing 
is active. If bonusing is active, the floor controller next determines 
whether the bonus pool amount has dropped below a predetermined 
minimum level called the "turn-ofl" level in 5fi0. This minimum amount 



or noor can be set by the casino and provides a bulTcr to account for Iar«cj 
bonus awards and/or multiple bonus awards that could cause the bonus 
payout to exceed the bonus pool. Therefore, if the bonus pool drops below 
the turn-off level, the method 550 branches back to step 552 and turns 
off bonusing. As will described further below, the bonusing remains off 
until such time as the bonus pool builds up past another miniiniiin level 
called the "turn-on" level. 

Returning to step 558, if the bonus is currently not active, the floor 
controller determines at step 562 whether the bonus pool has reached a 
predetermined turn-on level. This turn-on level can also be set by the 
casino and provides a buffer above the turn-off level to insure tiiat the 
bonusing does not behave erratically, i.e., bonusing rapidly switching 
between on and off. If the bonus pool is not above the turn-on level, 
bonusing is again turned off in step 552. 

If the bonus pool has" reached the turn-on level, the noor controller 
checks to see whether other bonus conditions arc met at step 5G-1. These 
bonus conditions can include, but are not limited to, a minimum period 
of time since the last bonus activation, a minimum level of play in tiio 
time period prior to the bonus pool reaching tlio turn on level, a 
predetermined time of day, or other predetermined conditions. These 
conditions give the casino additional control over the bonusing 
promotions. If the conditions are not met, the method 550 branches back 
to step 552 where the bonusing is again turned off. If. liowcvor, the 
conditions are met in step 564, the bonus is turned on at stop 56G and the 
method 550 branches to step 554 where the machine activity is again 
monitored. 

In the preferred embodiment, the method 550 is embodied in 
soffware that is executed by each of the floor controllers in the system. 
These floor controllers are then responsible for activating or deactivating 
the bonusing for the individual machines connected thereto. The .«?ystem 



allows the noor controller to have multiple bonus pools and to have 
certain of the machines associated with a given bonus pool. Thus, the 
floor controller can implement multiple bonusing promotions 
simultaneously. 

This system also allows for machines connected to difTcrcnt floor 
controllers to be combined into a single bonusing promotion. In this case, 
one of the floor controllers assumes primaty responsibility for managing 
the bonus pool while the other floor controllers act as intermediaries 
between the primary floor controller and the machines connected to the 
other floor controllers. Thus, the system according to the invention allows 
for much greater flexibility in running bonusing promotionnls than 
heretofore possible. Prior art systems required certain predetermined 
machines to be connected into a bank for any given bonus award such as 
a progressive bonus. The system according to the invention allows any 
mac!)ine in the casino to be combined in a bonus type situation. The 
system also insures that the bonusing promotionals will operate 
substantially in the black, i.e., the bonus pool is greater than the bonus 
payouts. 

Having described and illustrated the principles of the invention in 
a preferred embodiment thereof, it should be apparent that the invention 
can be modified in arrangement and detail without departing from such 
principles. For example, although an Ethernet network was described in 
the preferred embodiment of the invention, other high-speed networks 
such as wireless networks could be used in place thereof. I claim all 
modifications and variation coming within the spirit and scope of the 
following claims. 
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Tho claims defining the invention are as follows: 

1. A method of operating gaminB devices inlerconnoct«d by a 
computer network to a host computer comprising: 

sending a reconfiguration command from the liost computer to a 

s gaming device over the network; 

receiving the reconfiguration command at Iho gaming device; and 
reconfiguring the gaming device responsive to the received 
reconfiguration command, wherein the gaming device reconfigures .ts 
payout schedule in accordance with the received reconfiguration 
10 command. 

2. A method of operating gaming devices according U> claim I . 
wherein the step of reconfiguring tlie gaming device includes 
reconfiguring the payout to be a multiple of a default payout schedule, 

3. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes 
reconfiguring the payout to be double the default payout schedule. 

2, 4 A method of operating gaming devices according Lo claim 2 

wherein the step of reconfiguring the gaming device includes limiting the 
multiple payout schedule to a predetermined percentage of the total 
gaming device handle. 

25 5 A method of operating gaming devices according to clnim 2 

wherein the step of reconfiguring the gaming device includes linuling the 
multiple payout schedule to a predetermined percentoge of the con.s .n. 
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6 A method of opcraUng gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the 
multiple payoutschedule to payoutonly when maximum coins are played. 

7. A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the 
multiple payout schedule to payout only >vhen an award falls within a 
predetermined range. 

8 A method of operating gaming devices according to claim 2 
wherein the step of reconfiguring the gaming device includes limiting the 
multiple payout schedule to payout only when a predetermined level of . 
activity is reached. 

9. A method of operating gaming devices according to claim 1 

further comprising: 

selecting two or more gaming devices on the network to be combined 
in a common jackpot having a common jackpot payout schedule; 

wherein the step of sending a reconfiguration command includes 
sending a reconfiguration command to each of the selected gaming 
devices; and 

wherein the step of reconfiguring the gaming device includes 
reconfiguring the selected gaming devices to payout out in accordance 
with the common jackpot payout schedule. 

10. A method of operating gaming devices according to claim 9 
wherein the step of reconfiguring the gaming device includes 
reconfiguring the selected gaming devices to payout out in accordance 
with the common, progressive jackpot payout schedule. 



30 



72 



11. A method of operating gaming devices according to claim 1 
wherein the step of sending a reconfiguration command includes sending 
a reconfiguration command describing a progressive jackpot payout 
schedule to each of the selected gaming devices. 

12. A method of operating gaming devices according to claim 1 
wherein the step of reconfiguring the gaming device includes 
reconfiguring the payout to be an automatic mystery payout. 

13. A method of operating gaming devices according to claim 12 
wherein the step of sending a reconfiguration command from the host 
computer to a gaming device via the network includes sending a 
reconfiguration command specifying the playing conditions under which 
the automatic mystery pay<?ut will payout. 

14. A method of operating gaming devices according to claim 1 
wherein the step of sending a reconfiguration command from the host 
computer to a gaming device via the network includes: 

detecting the time of day; and 

sending the reconfiguration command from the host computer to a 
gaming device via the network when the detected .time equals a 
predetermine time. 

15. A method ofopcrating gaming devices according to claim 14 
further comprising inputting the predetermined time on the host 
computer. 

16. A method of operating gaming devices according to claim 1 
further comprising: 



sending a status request D om the host computer to a Gaming device; 

and 

transmitting accounting data from the gaming device lo the host 
computer. 

17. A method of operating gaming devices according to claim 16 

further comprising: 

detecting a player associated with a gaming device; 

sending a player identification number from tlie gaming device to 
the host computer over the network; and 

associating the accounting daU witli the player idenUr.cation 
number for player tracking purposes. 

18. A method of operating gaming devices according to claim 17 

further comprising: 

sending a command including a credit amount from Uic host 
computer to the gaming device associated witli the player; and 

crediting the gaming device with the credit amount responsive to 
receipt of the command to provide cashless play. 

19. A method of operating gaming devices intprconnected by a 
computer network to a host computer comprising: 

detecting a player associated with a gaming device; 

sending a player identification number from U»c gaming device to 
the host computer over the network; 

sending a status request from the host computer to a gaming device; 

transmitting accounting data from the gaming device to the host 
computer over the same network; and 

associating the accounting data with the player identification 
number for player tracking purposes. 
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20. A mcUiod of operating gaming devices according to claim 19 
further comprising reconfiguring a gaming device over the network, 
wherein the reconfigured gaming device modifies a jackpot payout 
schedule associated therewith. 

21. A method ofoperaUng gaming devices interconnected by a 
computer network to a host computer, the method comprising: 

detccUng a player associated with a gaming device; 
sending a reconfiguration command from the liost computer to the 
player's gaming device via the network; 

receiving the reconfiguration command at the player's gaming 

device; and 

reconfiguring the player's gaming device responsive to the received 
reconfiguration command, wherein the player's gaming device 
reconfigures its payout schedule in accordance with the received 
reconfiguration command. 

22. A method of operating gaming devices according to claim 21 
wherein the step of reconfiguring the player's gaming device responsive 
to receipt of the reconfiguration command includes^dding an extra bonus 
to the payout schedule. 

23. A method of operating gaming devices according to claim 21 
wherein the step of reconfiguring the player's gaming device responsive 
to receipt of the reconfiguration command includes adding a progressive 
jackpot to the payout schedule. 

24. A method of operating gaming devices according to claim 21 
further comprising determining whether the player satisfies a 
predetermined criteria. 



25. A method of opcraUng gaming devices according to claim 24 
wherein tlie step of determining whether the player satisfies a 
predetermined criteria includes determining whetl^er the player is a 
member of a club. 

26. A method of operating gaming devices according to claim 24 
wherein the step of determining whether the player satisfies a 
predetermined criteria includes determining whether the player has 
reached a predetermined level of activity. 

27. A method of operating gaming devices according to claim 26 
wherein the step of determining whether the player has readied a 
predetermined level of activity includes: 

' detecting the level of activity and the time period over which the 

activity occurs; and 

transmitting the activity, level and the time period to. the host 

computer via the network. 

28. A system for operating a plurality of gaming dcvico.«? having 
serial interfaces, the system comprising: 

a host computer; 

a network interconnecting the gaming devices to the liost computer; 
means within the computer for transmitting a reconnguration 

command to a gaming device; 

means within each gaming device for receiving the reconfiguration 
command transmitted to the gaming device; and 

means within eacli gaming device for reconfiguring the gaming 
device responsive to the received reconfiguration command, wherein the 
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earning device reconfigures its payout schedule in accordance witli the 
received reconfiguralibn command. 

29. A^si^S^^^o^^^^ a plurality of gaming devices 

according to claim 28 comprising: 

means within eadi gaming device for ide^ 

with each earning; de>«ce;;;Jj^^^f ■-: 

m^ans within eaXg^ming device for sending the player identity 
from the player's gaming device to the host computer via the network; 

and y.-;^^ ■ 

means within the host computer for receiving the player identity. 

30. A systenT for operating a plurality of gaming devices 
according to claim 29 wherein Uic means within the computer for 
transmitting a reconfiguration command to each one of the gaming 
devices includes means within the computer for transmitting a 
reconfiguration command to the player's gaming device responsive to the 
received player identity. 

31. A system for operating a plurality of gaming devices 
according to claim 28 wherein the host computer comprises at least one 
floor controller. - • ; . 

32. A system for operating a plurality of gaming devices 
according to claim 31 wherein the host computer comprises a file server. 

33. A system for operating a plurality of gaming devices 
according to claim 32 wherein the network comprises: 

a current loop network coupled between the fioor controller and a 
plurality of associated gaming devices; and 
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a hig^i^^^^S^pcd the noor controller and the 

file scrver.i^^ai^^^t^.^ ^ . 

34. J^^^^^^^pSatiSe' a plurality of gaming devices 
according to "claim 33 WljS^Sitlie network includes a plurality ofcurront 

loop networks, an(r^^^^^i|ll;; ^^ -^^^ 

wherein'Se floor controilcrincludes a communication board having 
a plurality of^SS^S?i^^terfaces^ coupling to the plurality of 
current loop'^^^^^^ui^jcation board having a plurality of 
microproccsso^cSlffiS^cS^^ for the transmissions 

on an associated xurrcntlloop network, Uio comnunucaUon Imaid 



including a'-'S^KfdriJSr' interposed between the plurality of 
microprocessors and Uio plurality ofcurront loop networks. 



35. A'systcm' Jor operating a plurality of gaming deviixs.s 
according to claim 28 wherein the means within each gaming device for 
receiving the reconfigiration command transmitted to the gaming device 
comprises a daU communication node coupled to the network and coupled 
to the serial interface of the associated gaming device, wherein the data 
communication node mon^^^^^^^ transmissions on the network an.l 
determines which traSmi^ssion^^ transmitted to the associated ganiing 
device. 

36. '^SsSm^'for'Tpcra^^ a plurality of gaming dcvicos 
accordingto ciaim SS wherein the data communication node includes: 




a controller; 



a serial machine into coupled between the controller and the 
serial interfo^^of^ gamine device for receiving data from 

the associaSdfgS^ and transmitting tlie received 

reconfiguration comrnand to the gaming device. 
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37. A system for operating a plurality of utimum devices 
according to claim 28 including a non-volatile memory within each 
gaming device for storing a unique gaming device identir.c;.tion number 
to uniquely identify the gaming device on the network. 

38. A system for operating a plurality of Kaminy devices 

according to claim 37 including: 

means within each gaming device for reading the unique Kaniiny 

idcntincation number; and 

ntoans within each gaming device for transnnittinr. the uniquo 
gaminjj identification number to Uic host compuUir. 

39. A system for operating a plurality, of Kainim; devices 
accordinc Lo claim 37 including a machine conr.iiuration circuit for 
idcMitifying the type of yarning device. 

AO. A method of providing feedback to a u.ser in..u:rtini: a us.m- 
•Hlrnlir.cntion card having a unic.ue u.sor idontiHcation nu.nh..r ..uod.d 
thoroon into a i;ainin(! device, the method comprisini-: 

rcccivinK tlic card into a card rcadur op<!«iiiii:; 

sensing the number on the card; 

determining whether the sensed number is a valid identillcation 
ninnber; and 

providing feedback to the u.scr adjacent tlu; card rr.:u\v.r ..piM.in,:. the 
feedback comprising a positive feedback signal if Ihe .s.nsed nundnM- is a 
valid idcntincation number and a negative feedback signal if Iho sensed 
number is. not a valid identification number. 

41. A method of providing feedback to a user according lo claim 
40 wherein the step of providing feedback to the user adjacent to lUo card 



rcadcropcnmgincludcsprovidinfivis«aircccnK,ckar«undllu,cardn.ulo^ 
opening. 

42. A meUiod of providinR feedback to a user according to claim 

4 1 wherein the step of providing feedback to the user adjacent to the card 
reader opnning includes providing a first visual signal having a first color 
ifthe sensed number is a valid identification number and a second visual 
signal having a second color, different from the first color, if the sensed 
number is not a valid identification number 

4X A method of providing feedback l« a user according to claim 

42 wherein the step of providing a first visual signal having a first color 
if tlu. sensed number is a valid identificatio . n .uMher inchulos provuhng 
a first visual signal having n green color i; H.o s.-.seu number is a vahd. 

idjMitificalion numhnr; and 

wherein the step ofproviding a second visual signal having a s.rf.»nd 
,„,or if the sensed nund.er is not a valid identification nun.ber inclu.les 
providing a s.^cond visual signal having a r.d coh.r ifthe s..ns.Ml nun.ber 
is not a vali«l identification nuniher. 

44. A method ofproviding f.:cdl,ack to a us..r ac«.rding to clain. 
42 wherein the step of determining whether the sensed number is a valid 
identification number includes providing a third visual signal having a 
third color, diirercnt fron. the first and second colors, during the p.Mulency 
of the determining step. 

45. A method of providing feedback to a user according Lo claim 
4 1 wherein the step ofproviding feedback lo the user adjacent to the card 
reader opening includes actuating a plurality of light emitting diodes 
arranged around Uie card reader opening. 
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46 A method or providing fcodback to a user according to d,„™ 

40 wherein the step of deten^inin, whether the sensed „.»nber ,s a vahd 
lunca«onnun,berinc.udescomparin,toap.ur,r.tyofprede.em.,ned 

valid identincation numbers. 

47 A card reader having user feedback which reads a user 
identiltion card having a user identiHcation number encoded thereon 

comprising: 

a bezel defining a card reader opening; 

n^eans for sensing the user identincation number on the card; 
„.eans for determining wbether the sensed number .s a vai.d 

identification number; and 

means for providing visual feedback to the user -1^-" ' ^^^ ^ 
reader opening, the visuaUeedbackcn,prisingar,rstv,sua.s,enlftl.c 

r„;ednumberisava,ididentincationnun,berandasecondv,.,a,s,.,.a, 
if the sensed number is not a valid idenUfication number. 

48 A card reader having user feedback accordi,.,- to claim 47 
wherein the means for providing visual feedback includes a plural.t, of 
hght emitting diodes disposed around the card reader openmg. 

40 A card reader having user feedback according to clnin, 4« 
wherein the light emitting diodes include dual light emitting diodes for 
producing both the first and the second visual s.gnals. 

50 A card reader having user feedback according to claim 47 
wherein the user identincation card includes a plurality of holes winch 
:„::etheuseridentificationnumberandwbicharearra„ged,nco.„ 

and wherein the means for sensing the user identiP.cat.on numl., on the 
card includes an optical card reader. 
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51. A card roador having user focdbnck accordinu to clnirn r.O 
wherein tho optical card reader includes: 

a plurality of light emitting diodes disposed on a first s.de of 

card reader opening; and 

a plurality of photodetectors disposed on a second side o the card 
opposite the first side for detecting the light emitted by the p.urahty of 
light emitting diodes. 

52 A card reader having user feedback according to claim 5 1 
wherein the lightemilting diodes and the photodetectors are arranged ,n 
opposing pairs for detecting the holes of a respective column. 

53. A card reader having user feedback according to claim 47 

further including; 

' „eansrordetectinetheorientalionoftl.ecnrd-,nnd 

wherein the means for determining whether the sensed number ,s 
a valid idenlificaUon number transposes the sensed number aecord.ng to 
the orientation detected by the detection means. 

54 A card reader having user feedback according to clann 47 
further including first and second guide members -lisposed on oppos.ng 
lateral sides of the card reader opening for guiding a user ident:.,caUon 
card thcrcalong. 

55. A method of operating gaming devices interconnected by a 
computer network to a host computer comprising: 

mentoring tlie activity of the gaming devices; 

detecting the amount of money played on the gaming dov.ces; 

allocating a predetermined percentage of the money played to a 
bonus pool; 
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J, .-^ininc the level of Ihc bonus pool; and 
pool level exceeds a turn-on level. 

r4pviccs interconnected by a 
tiR A method ofoperating gaming devices mi, 

turn-off level. 

„ A method .rc-craUne earning devices intorconnoctod by a 
. network to a host computer accorain« to ch,im 55 compnsmg. 
--"d— - time peHod since the h.st hon. tahio activation; 

deactivating the bonus payout tabie .hen the tin.e period exceeds 
a minimum period of time. 

58 A method of operating gaming devices i„torc.„„>ectnd by n 
.„puLnet»or.toahostcomputeraccordin.t„c,aim55co,npr,s,„. 

determining the level ofplay for a gamins device; 

delrvating the bonus payout tabie in the gaming dev.ce when the 

level of play falls below a predetermined level. 

,9 A method of operating gaming devices interconnected by a 
computer network to a host computer according U. dain, 5S compr.s.ng. 

riofnrmininc the time of day; 

deaXtin: the bonus payout table when the tin. of day .s not 
Within a predetermined period of tune. 

^:„rT flnvicos interconnected by a 
fin A method of opcraUng gammg devices mtc 

nlorU to a host computer according to claim 55 compr.smg. 



detecting the amount of money paid out ns bonuses on tl,e «n,nin« 
devices; 

modifying the bonus pool by the amount of money pn.d out as 
bonuses; 

determining the level of tho bonus pool; and 

deactivating a bonus payout table in a gaming device when the 
bonus pool level falls below a turn-off level. 

61 A method of operating ganung devices interconnected by a 
computer network to a host computer according to claim 60 wherein the 
turn-on level is above the turn-off level. 
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ABSTRACT OF THE DISCLOSURE 
A system for monitoring and configuring gnniing devices 
interconnected over a high-speed network is disclosed. The system can 
support a file server, one or more floor controllers, one or more p.t 
terminals, and other terminals all interconnected over the network. Each 
gaming device includes an electronic module which allows the ,a„nng 
dc ice to communicate with a floor controller over a current loop network. 
The electronic module includes a player tracking module and a data 
communication node. The player tracking module includes a card reader 
for detecting a player tracking card inserted therein which identifies the 
player The data communication node communicates with both the floor 
coniroller and the gaming device. The data communication node 
communicates with the gaming device over a serial interface through 
which the data communication node IransmiLs reconflguraUon 
commands. The gaming device reconfigures its payout schedule 
responsive to the reconfiguration commands to provide a vanety of 
promotional bonuses such as multiple jackpot bonuses, mystery jackpot 
bonuses, progressive jackpot bonuses, or player specific bonuses. 
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